Conflicts:
	CMakeLists.txt

CMakeLists.txt: fix dependencies to allow make -j

CMakeLists.txt: let picowota_build_combined add files to clean target

I always forget what the PICO_BOARD bit needs to be, so just write it
down.

This allows to drop the nasty hardcoded address in CMakeLists.txt.

As ${APP_BIN} and ${APP_HDR_BIN} are not true targets, the dependency on them
effectively only required the .bin files to be present.

When building with make -j, this led to the situation that the target
${NAME}_hdr finished *before* compiling the project, in case there were .bin
files left from previous builds, leading to ${NAME}_hdr.bin files containing
invalid CRCs.

Setting the dependencies on ${NAME} fixes this issue. The reasoning is that if
target ${NAME} is built, ${APP_BIN} should have been generated. There is no
need to depend on both ${NAME} and ${NAME}_hdr, as ${NAME}_hdr already depends
on ${NAME}.

We observed strange issues that (among other things) revealed that make clean
did not really make things as clean as it could. This is an attempt to clean up
various files generated.

Reported by ghubcoder in #2, debug builds were broken due to
incorrect MAX_NARG macro - it should be COMM_MAX_NARG.

Add WiFi AP mode

This aligns the behavior of the build variables, providing a helper function to do the job.

This allows to choose, when running cmake, whether the bootloader will connect to an existing AP (default behavior)
or fire up its own (by passing -DPICOWOTA_WIFI_AP=1) by using the same provided credentials.
DHCP requests are handled, with these settings the subnet is 192.168.4.1/24.

No more creds.c

Set PICOWOTA_WIFI_SSID/PICOWOTA_WIFI_PASS environment variables or
CMake variables.

May regret this!

This will be required for including into apps, so break it out.

Looks like removing printf drops about 10kB.

It works! Unceremoniously bailing out on the WiFi driver without
shutting it down might not be great - handling the "GO" and "REBOOT"
commands gracefully in the main loop would probably be better.

But hey, it works!

Now whatever arrives will get stored, and then used up by as many stages
as possible.

...but not it's obvious - we can't assume each packet nicely
encapsulates a single stage, it might all arrive in one go.
So the current "recv" implementation can't work. d'oh!

Don't allow data which is too long.

Now isolated for easy re-use. Should split it into a separate library.

Based on the Pi example