Centralize override and temp target activation

[bjorkert]

This rewrite was done because overrides activated from the watch were not sent to Nightscout until they were cancelled. The change has successfully been tested in real-world use for several days with no issues.

Every entry point routes activation and cancellation through AdjustmentManager, which performs the whole sequence in one Core Data transaction: end every enabled adjustment and record each as a run entry, enable the requested one, then apply the side effects in a fixed order. Commands are serialized, so two arriving at once cannot interleave.

The run entry carries the elapsed duration to Nightscout and draws the finished band on the home chart. uploadOverrideRuns deletes the entry at the run's own created_at and re-posts it there, so the cleanup holds for a preset row whose date moves on every activation, and the run upload window keys on endDate so an adjustment that ran for more than a day still retracts its placeholder. deleteNightscoutOverride filters on event type.

APSManager.recomputeDetermination() claims the loop guard for a determination-only run. It yields to the loop, which it never delays, and both the manager and the Adjustments view models go through it.

A custom, non-preset adjustment is stored disabled and activated by object ID, so storeTempTarget returns the inserted row's NSManagedObjectID.

The watch acknowledges a command from the returned outcome, and its failure acknowledgment applies only to messages carrying none of the recognized payloads. A remote cancel with nothing running is the state the command asked for.

[bjornoleh]

... the run upload window keys on endDate so an adjustment that ran for more than a day still retracts its placeholder. deleteNightscoutOverride filters on event type.

Not sure if I read this correctly, but does this mean it will also fix #1146?