Decide whether we want to keep shutdown, stop endpoints / what should they do

Currently Hyperion implements the following endpoints:

* PUT `/stop`
`stop` is valid if Hyperion is not `IDLE`, `ABORTING`
`stop` implements an asynchronous abort of the currently executing plan by calling `abort()` on the run engine, and if successful sets the status to `ABORTING`
`stop` as an endpoint is not particularly useful in UDC mode (#1150) since as currently implemented abort will immediately resume collection upon polling the next instruction from Agamemnon

* `shutdown` (this is implemented internally but not exposed via REST)
`shutdown` first performs `stop`, then enqueues a shutdown command, which when picked up by the main loop exits the loop. However, due to a `Thread.join()` on the Flask daemon thread, Hyperion does not exit but continues to serve API requests (although attempts at further plan execution will fail because the runner is no longer looping through instructions)

See also #188 for required restart functionality in containerised hyperion.
Shutdown does seem to be useful for at least implementing restart for Hyperion, but that would require it to actually exit, whether we still want a non-terminating shutdown is debatable.

## Acceptance Criteria
- We've determined whether we still need these endpoints and either removed them or implemented them.