Decouple project top-level from RP2040/Pico

[mcknly]

Finish the work that began in PR #6 - decouple project top-level from MCU platform and remove any references to RP2040/Pico, move all HW-related things to the hardware/ subdirectory.

Work on hw-decouple branch.

Still to-do:

• Add a variable for FreeRTOS MCU port sub-path (root CMakeLists.txt still has include($ENV{FREERTOS_KERNEL_PATH}/portable/ThirdParty/GCC/RP2040/FreeRTOS_Kernel_import.cmake)
• Move RP2040-specific target_link_libraries in root CMakeLists.txt to the hw_libs variable in hardware/rp2040/prebuild.cmake
• Remove references to RP2040 in cli/node_proc.c
• Other stuff that was missed?

[mcknly]

Also need a way to automate downloading the PicoSDK if it does not already exist, and move this functionality into the hardware-specific CMake file - potentially could use ExternalProject module for this purpose. Top level README should not refer to $PICO_SDK_PATH. This auto-cloning script could also be used for the FreeRTOS kernel.

[biot]

Why not just use git submodules for this? They need dealing with anyway, for microshell and git_version.

[Kintar]

I don't think submodules are the way to go for board-specific stuff, otherwise running a git clone --recurse-submodules or a simple git submodule update --init --recursive will pull down WAAAAAYYYYY too much crap once we support multiple boards.

We could always use the CMake FetchContent module to allow each HAL layer to automagically clone the necessary pieces. Or we can take a page from the VSCode Pico extension and do the whole bloody toolchain into <$HOME|%USERHOME%>/.pico.

[mcknly]

@Kintar agreed, I think the ability for CMake to pull in modules for FreeRTOS/relevant SDKs based on PLATFORM setting in project.cmake would be the way to go, but optionally if the user had the appropriate env variables set (as in FREERTOS_KERNEL_PATH and PICO_SDK PATH today), it would take no action to download those pieces.