Consider tidying up/splitting up BlueskyContext

[callumforrester]

BlueskyContext has become a very large class and is arguably bloated. It also exposes a mix of public fields and methods which may be hard to work with. We should consider splitting it up and neatening up the API.

[DiamondJoseph]

We may also be able to use some new Pydantic 2 functionality: e.g. revisiting the behaviour of inject and our device reference handling.

https://docs.pydantic.dev/latest/concepts/types/#handling-third-party-types

Probably makes sense to invoke #526 while reconsidering the API

[DiamondJoseph]

notes:

Assuming that blueapi's API's purpose is to enable autogenerating forms for UI, something like #526, maybe even returning limits per device (#519), device priority (is this ever more complex than default value when one is provided?), Plan function axis plotting preference (special docstring fields?). Better exposure of subdevices?

Is plotting going to be restricted only to those plans that use a ScanSpec? If so, are existing plans going to be refactored to have a default scanspec for plotting?

If blueapi becomes exposed through the graph, then that API is graphql and some of the more optional parts become easier to handle by only returning if requested.