Implement Debug and Release builds in PlatformIO

[jeffkowalski]

Brian says: Figuring out how to get Debug and Release builds in PlatformIO should be easy but I don’t know how yet. Set up the code so that LOGI (informational logs) don’t get emitted in release mode.

[jeffkowalski]

Typically, in a platformio.ini - centric way, one would define two different default targets (e.g. ...:debug and ...:release) with appropriate -DDEBUG=1 in debug and perhaps optimization flags in release. (There's no reason to have symbol preservation with -g, because our hw platforms don't readily support live debugging).
But the key question is - how do you expect to have this work in your dev env? For VSCode, I'm not sure how one selects between the debug/release targets. (I know how I do it in emacs, but that's my happy island). How should it work?

[brianmathews]

Checkin 142e910 implements these:

1. a tasks.json for VScode to have build targets. You select one of them on the status bar at the bottom of the VScode screen
2. an updated platform.ini that implements the different build targets for each chip type, and runs a pre-build python script to create the build information datestamp, as well as defining several variables for debug vs. release and setting different optimization levels (debug symbols vs. optimized code)
3. Changed the .gitignore to no longer exclude the important sdkconfig.* files. These are what hold the settings for the boot logging needed to prevent UART boot garbage being emitted into the KX radio. It also reduces the wifi power to save battery and prevent WiFi noise on HF bands.
4. Changed the default logging level for each build type and removed the global setting that was in the setup.cpp.
5. Created a new handler_version.cpp (Get method) so that the HTML/JS code can pull the version from the firmware (and the Debug vs. Release tag).
6. Updated the banner \<H3> element to show the version and build type.