Provide machine-readable "reason" in RunStop

[DominicOram]

At DLS MX we have a callback that where we want to do different things based on how the plan failed.

Currently, when an exception occurs in a plan the string representation of the error gets put into the reason field of the RunStop. Usually, the string representation is the human readable description of the error and so is useful for reporting to a user but hard to guarantee that it can be cleanly inspected to give a machine-readable error type.

If we added an extra optional field to the RunStop of something like exception_type that gave the class of the exception we could use this to determine what to do in the callback. This would involve:

• Adding the optional field to RunStop
• Adding the optional field to close_run
• Modifying https://github.com/bluesky/bluesky/blob/3bce96b85558993499174be7eebcd09f270a9271/src/bluesky/run_engine.py#L1781 to also provide something like str(type(err))

There is currently a data_type in the RunStop. As far as I can tell this doesn't seem to be used I guess we could re-appropriate that but it seems messy.

[tacaswell]

Rather than exception_type I would prefer we either make reason "str or object" (in json language) or make the new field an "object" so we can grow it and/or customize it locally without having to make changes upstream.

The string reason is something we threw in early as as "this seems useful for post-mortem" but to my knowledge have actually done little with it.

Until very recently the keys in RunStop were not locked down (I think we locked it down as part of the cleanup @evalott100 did in 2023), another escape hatch is to re-relax that (but my guess is that there is not a lot of enthusiasm for it).