A problem that should be solved elsewhere.
Pulse timestamp should actually be in the future.

- Mostly due to having to maintain the same inconsistency with the API.
Cleaning up micromanagement of stateTimestamps

- As the way pulseTimestamp changed, some of the integration tests that
  got changed last time is getting changed, again.
- This is mostly to correct the "reversed" handling of the pulse point
  in relation to the shifted deduction point.
- The stateTimestamp now moves forward if the unadjusted time is
  supplied for an updateResources call.
- Split off the siloPulseTimestamp calculation from the resource because
  the pulse may happen differently (never mind how nothing is ever
  accurate).
- More care used to validate the integration testing, but that really
  shouldn't be fully relied on.  More unit tests relevant to this change
  have been added.
- Reinforcement helper method will change stateTimestamp, assuming API
  is always accurate (yeah right).
Keyword arguments should be called as one.
Return value for updateResource method

- It now returns list of resource typeIDs updated.
Be explicit about objects outside of sessions.

- The objects loaded are used as deatched objects quite extensively by
  the manager and other users.  They are now expunged when loaded.
- Also due to this it's best to not expire objects after commits.
No more inconsistent stateTimestamp handling

- Ensure all updates to stateTimestamp is done in one place
- Also this allows the updateResource method to optionally include the
  stateTimestamp, which is provided by the EVE API and so it's a valid
  value to keep track of.
- This also allow the manager to be agnostic about handling special
  cases and possible intricacy between the different timestamps.
Implement the updateTower method.