Improve cleanup after lifecycle startup errors
LifecycleManager#startServices() can return various error values. Currently the Android app doesn't call stopServices() unless startup succeeded, whereas the headless app calls stopServices() regardless.
If the system clock is unreasonable, LifecycleManagerImpl#startServices() doesn't release the startStopSemaphore before returning, so stopServices() will block indefinitely - but the semaphore is released in the case of other errors.
We should tidy all of this up so that either stopServices() doesn't need to be called if startup fails, or so that it can be called safely and without blocking indefinitely, and so that services and the DB have a clear contract for whether they will be started and/or stopped if an error happens.
Related to #2222 (closed).