Consider BlueAPI as a library rather than an Application

[DominicOram]

The current assumption of running BlueAPI is that it is the core application that is configured to load code from other repositories. This has a few issues:

• BlueAPI owns the venv, causing issues like Document How to Add Non-Scratch Dependencies #1316 and Favour village extended image over scratch area #1289
• BlueAPI owns setting up things like logging, meaning any requests for changes on this mean adding more configuration to BlueAPI.

Instead, if BlueAPI was a module and I could do something like:

import blueapi
import my_plans
import my_devices

blueapi.add_plans(my_plans)
blueapi.add_devices(my_devices)
blueapi.run()

Then I (as a science village) could have ownership over the venv, and add any initial setup/teardown I wanted. This does have the disadvantage that science villages will have to maintain the deployments more themselves and that it could lead to lots of different ways of starting blueAPI up.

Acceptance Criteria

• This option is considered as a fix for future issues