Ability for Header Authors to add functionality to application

Currently there is a situation where some Story Authors are choosing not to upgrade to the latest official Twine 1.4.1, and are instead using a modified version of Twine 1.3.6 alpha due to it offering better supporting their Story Format header of choice. (SugarCube)

Some of features in the modified version could be added to the office version but others are specific to the SugarCube header.

Because the different Headers (Jonah, Sugarcane, SugarCube, etc) support different features/default macros, there appears to be a need for the ability to allow the Header Authors to influence/change how the Twine GUI works depending on the Header (Story Format) selected.

This would reduce the amount of hard-wiring required to support a feature that is not common to all Headers.

Contained within this branch is a very basic example of a Header class system, which allows a Header Author to supply a Python class file along with their "header.html" file, this class could contain code that changes the application.

The basic example allows Header Authors to do the following:

1. Indicate what name to show in the Story Format list.

2. Indicate which external files to embed within the generated output.
eg. jonah/code.js if Jonah; sugarcane/code.js if Sugarcane

3. Allow for different endtag formats.
eg. both endtag_name and /tag_name formats.

4. Indicate which macros support nesting.
eg. IF and SILENT by default; other headers may include others.

Other functionality like, which macros also behave as links and need highlighting,  can be added as needed.