Revamp widget connector

Resolves (in part) #308

This adds support for tracking widget changes in the customizer, improves the logic for tracking changes on the widgets admin page, and allows tracking of widget changes no matter how they are made (e.g. via WP-CLI).

New features:

- Log changes to widgets in the customizer
- Handle batch operations on widgets
- Add deactivated/reactivated actions
- Add basic support for old single widgets
- Remove hooks which tie into the UI, and rely solely on actions which fire when the underlying data is modified.
- Note: `sidebar` Stream meta has been renamed to `sidebar_id` to correspond with `widget_id`. No migration script to rename `stream` to `stream_id` has been included.

Todo:

 - [x] Improve behavior of logging movement of widgets between sidebars when in the customizer.
 - [x] Should `widget_id` ever be added as a context?
 - [x] When moving a widget from one sidebar to another, should there be one Stream record with two contexts, or two records with one context each?
 - [x] ~~Add database migrations for any changed stream meta (e.g. `sidebar` => `sidebar_id`)~~
 - [x] ~~Add widget edit link, in addition to the widget area edit link.~~ (See #521)
@westonruter `context` is always used in the context of the connector, so you don't really know what a `context` mean till you see how the connector stores/uses it. Adding it to meta shouldn't be a problem, it should even be encouraged, so it is more visible/clear in queries that might use it, instead of using the `context` field which might be ambiguous in queries.
/cc @fjarrett