Consider BlueAPI as a library rather than an Application

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 https://github.com/DiamondLightSource/blueapi/issues/1316 and https://github.com/DiamondLightSource/blueapi/issues/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:

```python
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