Refactor usage

- Removes the merging of revisions that share the same status and plan
This was accounting for a use case we don't have (where someone would force a revision to be created for something that is not a status and plan change). But we don't have the use case yet, and the plan history function is the wrong place to do it. It would only make sense when collecting charges in which case it might make more sense to have an alter hook and allow the user / module that is creating the extra revisions to decide what it wants to do with them / how to price them.
- Usage records now need an explicit revision_id, no need to guess and map them anymore. Huge win.
- Adds usage_group plugins and centralizes all usage handling logic there.
- Allows usage_group plugins to respond to events, simplifying the maintenance of usage over a license life cycle (change of plans, statuses, opening / closing of billing cycles) 
- Fixes the gap checking, making it check against plan history, not the full billing cycle length.
- Simplifies the charging of usage.
- Add the 'initial_quantity' property to gauges, to support registering an initial quantity right after the billing cycle has been opened.