Demark behavioural differences between plans and stubs, move orphaned plans into dodal.

[DiamondJoseph]

Bluesky distinguishes between plans: complete experimental proceedures, which open and close data collection runs, which may be part of a larger plan that collect data multiple times, but that might also be run alone to collect data, and plan_stubs: which do not create & complete data collection runs and are either isolated behaviours or building blocks for plans.

In order to make it clearer when a MsgGenerator can be safely used without considering the enclosing run, when it is required to manage a run and when running a procedure will create data documents, I think we should adopt this standard.

This change also adds the count and spec_scan plan previously from dls_bluesky_core, as remove this as a requirement for blueapi is long overdue and this is the last remnants of that module. count is a basic collection of a set of devices, equivalent to Mapping GDA's StaticScan. spec_scan is analogous to GDA's mscan command, constructing a generic N-dimensional trajectory for scanning.

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[DiamondJoseph]

@coretl @callumforrester do you have any idea why this is currently required? Previously we had a Spec[str] in blueapi and this did not cause issues- here in dodal, it seems we cannot have a Spec[str] or Spec[Movable].

"__getitem__" method not defined on type "type"Pylance[reportIndexIssue](https://github.com/microsoft/pyright/blob/main/docs/configuration.md#reportIndexIssue)

This is an issue in Pylance in the IDE and also in the type-checking step of the CI job.

[DiamondJoseph]

This was due to the discriminated_union decorator's type hinting not being adequate.
This change is therefore blocked until ScanSpec 0.7.3 can be released, which is blocked until time is spent to handle dataclasses.