Separate upgrade steps that operate on State from those that using the API

The PR separates upgrade steps that manipulate State from those that use the API. All State-using upgrade steps (typically DB migrations) are now run first, before all API-using steps. It is important that DB migrations and the like are run first as later upgrade steps often rely on them having already run. The previous way of defining upgrade steps made it too easy for this not to happen.

API-using steps are now given a context that only allows access to the API and similarly State-using steps can now only access State.

The messages for each commit follow.

---

upgrades: moved Step and Context to their own files

In preparation for upcoming changes where State requiring upgrade steps will be separated from API requiring ones.

Also removed unused "db" and "runner" fields from upgradeContext.

---

upgrades: introduce StateStep

It's now part of the Operation interface, but not used yet.

--- 

upgrades: StateSteps are now run as part of upgrades

All StateStep upgrade steps for a target are now run before other upgrade steps. Existing migration steps still need to be migrated and there's a number of cleanup steps required before this work can be considered done.

--- 

upgrades: migrated steps that manipulate state directly to be defined as such

--- 

upgrades: introduced APIContext

This is a limited upgrade context give to upgrade steps that use only the API. Existing steps like that have been updated to take APIContext instead of Context.

--- 

upgrades: test refactoring

Extracted the common parts of mockStateUpgradeStep and mockUpgradeStep, making the targets() helper unnecessary in the process.