Rework solution configuration and ST CMSIS/HAL integration

[josesimoes]

This PR addresses the discussions in #405 and also #429.
A couple of warnings:

• it's a work in progress
• I'm aware that it's huge but couldn't find a better way to deal with all the changes because it touches a lot of stuff
• I know it's not perfect, but it's a start

Having said that: it's a proposal open for review, discussion and criticism.

What's included (and in the works)

1. Add PowerShell script to download and "install" ST CMSIS and HAL files (this addresses the question of not having third party code in the repository).
2. The script is called when building a solution to make sure everything is available (this addresses the question of dealing with automated build processes).
3. Reworked the way the hardware features are added to a solution to make developer's life easier and not requiring a deep knowledge of what is "under the hood".
   1. The device series/variant is moved from platform selector to solutions settings.
   2. TinyBooter and TinyCLR each have a settings file to allow granular selection of what features are to be added on each flavor. These settings files merge the solution settings and each is the one that goes into the respective proj file (instead of the global one as before).
   3. These settings files have a simple True/False selector to choose what should be added. These properties latter reflect what is compiled/linked in the final image. Having this selection here and as a property allows them to be visible and accessible in the projs, build system and code.
   4. The features property allow that (using #defines) the calls to the HAL init/deinit functions are added or not according to the feature selection.
   5. There is a readme file with the instructions on how to build a new solution.
   6. The TinyBooter and TinyCLR projs are organized in a way that they don't need to be (almost...) touched when building a new solution. Unless a very particular change is required, of course.
   7. There is a HAL project (one for CLR and another for loaders) that includes all the features.
   8. All the stubs are now implemented as 'weak' functions. This makes things easier because it allows that all the stubs can now be compiled and always added by default because the linker will replace the 'weak' ones with the 'strong' implementation (when it exists) and the optimizations will remove the 'dead' code when they are not used.
   9. All this makes it very easy to add new series and MCUs (at least for ST parts, right now there is only the HAL for the F4xx series but any other series can be added with minimal effort by using the ST Cube files and taking advantage on the new organization).
4. The "new" HAL is total based in the CMSIS and HAL code supplied by ST.
5. The individual projects for the HAL features are now based in the ST HAL and follow the ST guidelines and philosophy.
6. The hardware configuration is now simpler because it uses the HAL naming and defines. This makes it easier to add new series/variants becuase the code knows what is available and what isn't and it adapts accordingly. E.g how many and which USARTS, SPI port, which pins belong where, etc.
   (GPIO, USART, SPI, I2C, power, flash and time are implemented; DA, ADC, PWM and USB are on the works)
7. CRC calculations are selectable between the software implementation and hardware based.
8. Most of the configurations and HAL options are now in the system_stm32f4xx.c in the solution folder, replacing what was in platform selector.
9. USB support (using ST middleware libs) should be much easier for both device and host. We are close to have USB connection for MFDeploy. It currently enumerates the NETMF device and receives the debug packets. The last part (replying to MFDeploy) is in the works.
10. The scatterfiles were reworked to use of the newlib nano and implement the stack/heap. The managed heap size is now automatic.
11. The "simple heap" was removed because the modern compilers can provide that and we can free NETMF from doing it. (There is still a small remapping required for the crypto libs).

Final notes:

• The changes are being included in both MCBSTM32F400 and STM32F4DISCOVERY. We only have available the STM32F4DISCOVERY board so we can't test the other hardware.
• Right now only the TinyBooter is compiling and tested (except USB).