Use BlueAPI default PathProvider

MX Should start using BlueAPI's pathprovider, which also means using numtracker. For this:
- Need to set up authentication and deploy numtracker. Where scientists don't want to rely on a central service, we will have to deploy a numtracker service on their beamline cluster (eg i03)
- Devices use the default path provider upon initialisation. If we want our own logic for file destinations and namings, we can use the path provider as a base provider and build our own path on top of that. For example see i24's [jungfrau initialisation in dodal](https://github.com/DiamondLightSource/dodal/blob/1d5983fee7c8a59edfeee2d0d45e649ac280b472/src/dodal/beamlines/i24.py#L147)

### How does the default provider work?:
- When BlueAPI starts up, it creates the [default path provider](https://github.com/DiamondLightSource/blueapi/blob/d237784d99a98b9f541db229ed04e5455c4a2b7c/src/blueapi/utils/path_provider.py#L7) and subscribes it to the RunEngine (in [this](https://github.com/DiamondLightSource/blueapi/blob/d237784d99a98b9f541db229ed04e5455c4a2b7c/src/blueapi/core/context.py#L162) file).
- It then injects a function to run whenver bluesky opens a run. When a run is open, a numtracker scan is created (see [create_scan](https://github.com/DiamondLightSource/blueapi/blob/main/src/blueapi/utils/numtracker.py#L42)). The return value here provides a scan number, a directory, and a file name. (The scan number increments by one for each open run). This information is then stored in RunEngine metadata
The instrument session is stored in the RunEngine metadata as soon as Blueapi [submits a task](https://github.com/DiamondLightSource/blueapi/blob/d237784d99a98b9f541db229ed04e5455c4a2b7c/src/blueapi/service/interface.py#L150).
- The base path provider uses numtracker to confirm the user is allowed to write to that visit directory, so we need to use numtracker. However, we are free to ignore all the information numtracker provides and track the run number ourselves.