WIP: Replace RunEngine management components with blueapi

[callumforrester]

Fixes #31

Changes:

• Add blueapi as a dependency
• Remove BlueskyRunner class and use RunEngineWorker from blueapi
• Replace experiment registry functionality with BlueskyContext from blueapi
• Create top-level plan for fast grid scans that handles the parameter translation previously handled by the experiment registry
• Replace composite device global variable with a device stored inside BlueskyContext

Still to do:

• Ensure equivalent tests in blueapi as for deleted runner class
• Any extra tests in artemis
• Error handling/status updates

To test:

1. A/B testing: confirm scan still runs as expected

[callumforrester]

Need to revert before merging

[callumforrester]

Possibly everything in this module should go in __main__, since it's just the error type left

[DominicOram]

main now has multiple plans listed here. We will need to run all of them

[callumforrester]

Added full_grid_scan too

[callumforrester]

From offline discussion with @DominicOram a couple of weeks ago:

• Ideally want stop capability (from StopOrStatus)
• Definitely want status: Allow getting the status from the RunEngineWorker and expose the status to the REST API blueapi#218
• Need to ensure Worker and BlueskyContext are tested to the same extent as BlueskyRunner: Ensure worker/context tests to same degree as artemis  blueapi#198
• Some mechanism for WarningExceptions, I was initially confused by this. After discussing with @dperl-dls and @DiamondJoseph, we felt it was better that blueapi/artemis has no knowledge of what constitutes a warning and what constitutes a fatal error to the greater UDC operation while said operation is under the control of GDA. Our idea was to split WarningException into several more specific exceptions, and have GDA simply know which types of error mean it can carry on and which don't. @DominicOram what do you think?

[callumforrester]

Also discussed: equivalent of skip_startup_connection in bluesky context

[DominicOram]

Yh, I'm happy for GDA to just examine the Exception

[callumforrester]

Also to do: validate on submit: DiamondLightSource/blueapi#213, could be a separate PR

[DominicOram]

Spun out #679 for warning refactor

[DominicOram]

This has become a bit unwieldy and out of date. I'm going to take what we have here (thanks @callumforrester) and split it into 3 or 4 different issues/PRs