What problem does this solve or what need does it fill?

The freecam controller uses a single component storing all state and config.

This is... odd, and not usually what we'd recommend. It makes it a bit harder to reuse,
and causes some UX problems when trying to twiddle values in an entity inspector.

What solution would you like?

Split the FreeCam component into two parts: one for state and one for settings.

Give the FreeCam (pretty) name to the settings (since that's the thing users should be defining / tweaking), and call the other one FreeCamState.

What alternative(s) have you considered?

Split this into three parts, adding another component just for keybindings. But eh, #435 is going to wreak havoc with that anyways.

We could also just leave it alone. It's not that bad.

Additional context

We should also consider changing how enabling/disabling the camera controls works, and move more of the system state into the component for reduced weirdness.

Those should all be separate PRs though, and again, #435 will force a refactor of our disabling mechanism, as input managers provide that functionality out of the box.