Move unique_id (configurably) earlier in the static init process

[byteit101]

Fixes #2373

Move unique_id (configurably) earlier in the static initialization process . This enables using the unique_id in C++ static initializers by default, and avoid the static initialization order fiasco.

I added the configuration in the off chance that someone would need to adjust it, but I think 1000 is probably a good-enough default. Values range from 101-65535, or "none", which is after 65535. Normal C++ static initializers are "none". Users can still manually specify to be earlier (101-999) without any configuration changes, via any of the following:

// C  & C++
__attribute__((constructor(101))) some_function() {}
// C++ only
__attribute__((init_priority(101))) some_class instance;
[[gnu::init_priority(101)]] some_class instance;

The following will all be initialized after unique_id is initialized, by default

// C  & C++
__attribute__((constructor(1001))) some_function() {}
__attribute__((constructor)) some_function() {}
// C++ only
__attribute__((init_priority(1001))) some_class instance;
[[gnu::init_priority(1001)]] some_class instance;
some_class instance;

[lurch]

I'm afraid that static initializers aren't something I know much about, but would there ever be a reason that you'd want to set this to -1 ?

[byteit101]

The current, existing behavior can be reverted to by setting to -1. I don't think there is a reason you couldn't use 65535 instead, but the default linker script order is that "-1" is after 65535 (I could call it 65536, but I think that may be more confusing, oddly enough)

Linker script: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_crt0/rp2040/memmap_default.ld#L79-L80

Note the .ctor.* are the ones with init_priority, and .ctor is the -1/default/old behavior

[byteit101]

If you would prefer, I can remove -1 and we then wait until someone hollers that we broke something? (I think that is unlikely, but not sure, as I haven't explicitly used init_priority before this year)

[lurch]

This is a @kilograham decision 😉