Ready for initial public release.

Create a goal to make a zip archive of the bundled RoboFont extension.

Include some background information about why I made this plus some
screenshots to get the visual message and demo across.

Also include a note about installation and license information.

Not using `HotKeyItem` due to the length checking made in
1391f70d79144518dda9d0294a9e8a8fc79904ff.

Remove the commented `NSFormatter` subclasses, and debug statements from
1391f70d79144518dda9d0294a9e8a8fc79904ff, and also rename our
single-letter variable.

Tried to create an `NSFormatter` subclass but kept getting this stupid
error:

    TypeError: isPartialStringValid:newEditingString:errorDescription::
    Need tuple of 3 arguments as result

and:

    TypeError:
    isPartialStringValid:proposedSelectedRange:originalString:originalSelectedRange:errorDescription::
    Need tuple of 4 arguments as result

which is freaking idiotic because if you look at the Cocoa documentation
you can see that both those methods return fraking `BOOL`s.

Also needed to keep renaming the subclass because every time I
reinstalled the extension, PyObjC or RoboFont or whatever would yell:

    Traceback (most recent call last):
      File "preferences_window.py", line 10, in <module>
      error: Booya2HotKeyFormatter is overriding existing Objective-C
      class

Anyway, ended up ditching the `NSFormatter` subclass because of that
_stupid_ nonsensical error and am now just checking for string length in
the input edit callback and forcing a max length there by resetting the
value to ensure it doesn't go over 1 character.

This fixes the bug mentioned in
8778928a0989ea938fb06f0dd4c6639a6f9148ca, allowing us to change the
preferred activation key and have it work immediately without first
having to relaunch RoboFont.

Separate preference handling into a new class and have the previous
preferences class handle only the preferences window.

We rename the old file to `preferences_window.py` and adjust the
`info.plist` key for the menu item accordingly.

Our new `Preference` class can now be imported from both
`equalize_sidebearings.py` and `preferences_window.py` without causing
confusion. I extracted it because asking for the
`DEFAULT_ACTIVATION_KEY` from `preferences_window.py` from
`equalize_sidebearings.py` would open the preferences window (bad).

We now save the preferred key using RoboFont's extension preferences
API.

When the text input in the preferences window is modified, the new key
preference gets saved.

BUG:
There's an issue with this implementation where the preferred key
doesn't become active until the next launch of RoboFont because
`EqualizeSidebearings` has its own instance of `Preferences` which has a
stale `activation_key`.