Model spec out of date

[jasongrout]

It looks like several PRs changed the model spec. We'll have to be more careful about this, perhaps with a test that generates the model spec and compares to the model spec document (which is also mostly auto-generated).

One released change:

• Make ToggleButtons respect passed style kwarg #1714 added description_width to the ToggleButtonsStyleModel without updating the spec document. This was released in 7.0.1.

Two unreleased changes:

• Selection widgets fixes #1822 makes nulls not possible in the ToggleButtons.button_style (https://github.com/jupyter-widgets/ipywidgets/pull/1822/files#diff-6d34727498411c9232fd0726eb7100c7L427).
• 1719 support more styles to toggle buttons #1834 introduces two attributes into the ToggleButtonStyleModel, button_color and font_weight. (We should also test the button_color one more time - the current theme I think changes the color slightly when the toggle item is selected, but button_color may overwrite that.)

In particular, I'm hesitant to release without resolving this issue for #1822 and #1834.

CC @SylvainCorlay

[jasongrout]

The only backwards-incompatible change is making nulls not possible in #1822.

The real problem is that we aren't quite equipped to deal with compatible versions of the model spec quite yet.

Some options:

1. Bump the spec to a minor version (e.g., backwards compatible), and back out the change in Selection widgets fixes #1822 that is backwards-incompatible (e.g., change Selection widgets fixes #1822 to let ToggleButtons.button_style take a null).
2. Branch and make a new 7.0.x release without Selection widgets fixes #1822 and 1719 support more styles to toggle buttons #1834. We still have the problem of Make ToggleButtons respect passed style kwarg #1714 being already released, though.

[jasongrout]

Here's what I think I'll pursue:

1. Bump the model spec version for jupyter-wigdets/controls a minor version bump to 1.1, and the controls npm package version to 1.1. This in turn should cause minor version bumps in html-manager, widgetsnbextension, and jupyterlab-manager, and ipywidgets.
2. Specify that model specs are the exact version number of the actual data (e.g., 1.0.0), not a semver range, like ^1.0. We do this because the model spec is a format that can be archived - we just need to know what the actual format of the saved data is, not what the saved data thinks can read it.
3. Implement logic in the reader (e.g., the frontend) which automatically adds ^ to the version when looking up a package to handle the format, i.e., if the model module version is 1.0, it will look in its registered modules for things that can handle version ^1.0. The assumption here can be overridden if there is an incompatibility.

[jasongrout]

Oh, and also: write a test that generates the spec from the python code, and fails if the spec in the repo does not match what is generated from the python code. That should catch any further incompatibilities from slipping in.

[jasongrout]

Fixed by #1854.