Provide a way to handle (internal) breaking changes

Now that MainNet is deployed, we loose the ability to reset the database at will as we did for TestNet.

This means that the following will have to be handled carefully:

### Database
- Change to a field's type
- Addition of new keys
- Addition of new record derived from blocks
- Removals are fine (because it just means unused data)

### API
- Addition of required fields to existing endpoint (we can use `json:omitempty` for optional fields)
- Change to existing URLs
- Additions of new endpoints are generally okay

### Consensus
I think in this area, we are still okay as the network is closed.

### Sync
Since the watcher node is going to be used by exchanges, we should treat it as we treat the API.

I suggest we add a `Breaking` label for any breaking change, and consider its inclusion carefully.

This is a project-wide proposal covering database changes, API compatibility, consensus, sync, and a proposed Breaking label. Start by reviewing how these areas and issue labels are currently handled; the work is done when the project has an agreed, documented approach for identifying and managing internal breaking changes.

Written by the indexing model from the issue text.