update podState, add setStateWithResult to match OmniBLE, from itsmojo

[marionbarker]

This PR is in response to a problem found in Trio, which uses the same submodules as Loop. The code difference was prepared and tested by @itsmojo.

Loop works fine without these changes, but also should continue to work.

When modifying OmniKit in a manner similar to OmniBLE (LoopKit/OmniBLE#125), it was discovered some code found in OmniBLE did not make it into OmniKit when that code was updated to SwiftUI.

From @itsmojo:

• "I think that this was just an accidental omission and that the OmniKit setStateWithResult should match the OmniBLE version which takes time into consideration when looking for changes between oldStatus & newStatus as well as oldHighlight and newHighlight."

Trio Issue: Extra messages exchanged with Omnipod

[itsmojo]

Ran various insulin delivery changing tests (automatic bolus, manual bolus, trying to bolusing with an on-going bolus, cancelling a bolus followed immediately by another bolus, automatic temp basal, manual temp basal, suspend, resume, etc) with a live pod and everything worked as expected. I also added additional debug code that would print out the {new,old}Status.bolusState and the {new,}oldStatus.basalDeliveryState in cases where they differed due to the additional !isFinished(at: date) testing and reran all the testing. By analyzing the Xcode logs I was to detect cases where shouldNotifyStatusUpdate was set to true solely because of the additional improvements. This allowed the HUD to show a change in delivery status change without a pod command having to be run. This was confirmed checking the time of a HUD update for the end of a manual temp basal against the pod comms logs.

[itsmojo]

LGTM