Protobuf splitting to reduce size of what is accessed at runtime

From @arntsonl in #1123:

Memory size is getting pretty big, I think its a good time to think about board settings vs user settings protobuf packages. We're at the point where calling protobuf breaks our core1 usb code, so we might want to think deeper on how to break up those two components.

So user settings MUST be under a certain size to ensure we don't break usb host, and board settings can be some big size.

My intuition is that the whole config is a "user config" in that it can be changed by the user, so rather than board vs. user, an alternative way to think about this is firmware initialization config (can be loaded at boot, isn't changed at runtime (instead only changed via webconfig)) vs. runtime config (changes at runtime, e.g. profile number, LS/DP/RS, etc.).

Read the referenced discussion in issue #1123, then trace where the protobuf configuration is accessed during firmware initialization, runtime changes, and core1 USB handling. The scope is not yet settled; done would require an agreed split that keeps runtime-accessed user settings within the USB size constraint without losing board or initialization configuration.