Generalise and consolidate callbacks

Following DiamondLightSource/hyperion#951 and DiamondLightSource/hyperion#947 we should look at making callbacks more generic, and activating/deactivating them based on the information emitted from the plan rather than specifying specific callback classes which are tied to the plan.

Currently we (will) do:
```python
@bpp.run_decorator(
md={
"activate_callbacks": [
"XraycentreZocaloCallback",
"GridscanISPyBCallback",
"XraycentreNexusCallback",
],
}
)
```
Which works efficiently but is not nice to read or use for scientists.

This issue is for discussion of the eventual solution, which could look something like:

```python
@bpp.run_decorator(
md={
"write_nexus": True,
"do_ispyb_deposition": True,
...
}
)
```
Or these parameters could be included in the hyperion parameters which are sent to the callbacks anyway.

Then, rather than having an `XrayCentreIspybCallback` we should have a generic `MXIspybCallback` or similar; likewise for nexus files. These should then interpret the documents emitted by the plan to determine the type of experiment being run and what information to include in a deposition or file. For Zocalo, we probably want a parameter that specifies the Zocalo recipes to run on the collection. (Or maybe Zocalo is already clever enough to decide this)

This will probably involve several sub-tickets:
- probably one each for genericising the nexus, ispyb and zocalo handlers
- at least for changing how callbacks are activated/deactivated

In any solution we will need to think carefully about how we identify which readings will be included in nexus files or ispyb depositions without re-adding much more ugly overhead to the plan.