Rework use of pico_cmake_set in board headers to make it slightly less magic/confusing

[kilograham]

Particularly, the fact that the lines are commented is confusing

• prefer "pico_cmake_set(var, value)" over "// pico_cmake_set var = value"
• prefer "pico_cmake_set_default(var, value)" over "// pico_cmake_set_default var = value"
• move these inside the header include guards as CLion complains

Note that the macros are defined in "pico.h" however that is not explicitly included by the board headers; this will probably confuse some VS code syntax highligting, so lets see how it looks - i'd prefer to avoid having to include a header just for this

[lurch]

Now that this "looks" like a proper macro, is there a risk that people might expect it to behave like a proper macro? E.g. if somebody did:

// board has 16M onboard flash
#define DEFAULT_MEMORY_SIZE (16 * 1024 * 1024)
pico_cmake_set_default(PICO_FLASH_SIZE_BYTES, DEFAULT_MEMORY_SIZE)
#ifndef PICO_FLASH_SIZE_BYTES
#define PICO_FLASH_SIZE_BYTES DEFAULT_MEMORY_SIZE
#endif

would it work as expected?

[lurch]

IMHO it would be great if this PR could also update https://github.com/raspberrypi/pico-sdk/blob/develop/tools/check_board_header.py to cope with this new syntax. That's normally something that I'd do myself, but I'm about to go on holiday 😎

[will-v-pi]

This does seem to work fine with VS Code when using compile_commands.json - although it might make people think they can use pico_cmake_set outside of the board headers, so it might be good to add some sort of guard against that? Or change the definition to pico_board_cmake_set to make it clearer that it only works in board headers?

[kilograham]

pico_board_cmake_set good idea - this also helps with something that had been bothering me that a commented out new style one looks a lot like an old style one!