Consider renaming `MP_STATE_PORT`

Before MP_REGISTER_ROOT_POINTER was added, a port could define additional root pointers in its mpconfigport.h. It made sense to refer to them via a distinct macro, hence MP_STATE_PORT, even though all ports alias that to MP_STATE_VM.

Now the MP_REGISTER_ROOT_POINTER feature can be used to implement root pointers for modules that mpstate.h does not know about, such as modules in extmod, or user c module. We could also consider moving some config-optional stuff that's currently in mpstate.h to use MP_REGISTER_ROOT_POINTER. But things defined with MP_REGISTER_ROOT_POINTER are no longer "port". So for example, in modbluetooth_nimble.c we use MP_STATE_PORT(bluetooth_nimble_root_pointers), but the only thing that's "port" about them is that bluetooth can be enabled by the port/board.

So I see three options:

1. Remove MP_STATE_PORT and just change everything to use MP_STATE_MEM.
2. Replace MP_STATE_PORT with MP_STATE_ROOT_POINTER and have that aliased to MP_STATE_VM in a common location (i.e. not ports' mpconfigport.h).
3. Same as (2) but move the generated root pointers into their own struct, and add a fourth field (between thread and vm) on mp_state_ctx_t, and have MP_STATE_ROOT_POINTER access that specifically.

(My vote is for (3), these variables are no more "vm" than they are "port", and should find a new home )

FWIW, This came up as a question on Discord because the embed port does not define MP_STATE_PORT.

Start by tracing MP_STATE_PORT and MP_REGISTER_ROOT_POINTER through mpstate.h, ports' mpconfigport.h, and modbluetooth_nimble.c, then compare how the embed port handles the missing macro. Review the three proposed layouts and identify all affected root-pointer definitions and call sites. Done means the project has a decided naming and storage approach applied consistently, with the affected ports and modules building successfully.