The way this works is by creating subclasses of the `Extra` class. These subclasses will have an order and a name. The name is the same one
specified in the `extras` list/dict given to the Markdown init function.

The order will be at which point the function will be executed. This is done by attaching the extra to a "Stage", a distinct step in the
markdown process (eg: forming paragraphs, processing links... etc). You can set the extra to run before or after the stage.

At the moment, extras are automatically registered, activated and executed by the Markdown class.

TODO:
* More elegant way to register and init extras
* Optimise `Stage.mark`
* Convert more extras to new class format

Stay up to date with master

Also converted `mermaid` extra as part of this process. As a plus,
you no longer need fenced-code-blocks activated to use mermaid.

Also added the ability for extras to be triggered before or after another extra

All block extras have now been converted

Still TODO is things like `footnotes` extra.
Also need to think of a system for extras to replace parts of the standard syntax

Merge master to pull in trentm#514 for conversion to new Extra format

Also fix tests not running on Windows

At time of commit, Python 3.5 is 2 years 9 months EOL.

…nto custom-extras

Resolve merge conflicts for PR

Allows extras to check exactly when they've been triggered - before or after certain stages

Remove unneeded type hints

Ended up implementing a `ItalicsAndBoldProcessor` ABC extra class for both
to piggy-back off of. Works by hashing text that we don't want processed and then doing nothing
with the other text. Hashed text is then replaced after I&B has run

Resolve merge conflicts for PR

Resolve merge conflicts for PR

Merge master to resolve PR conflicts

Resolve PR conflicts

Resolve conflicts for PR

Merge recent changes to `breaks` functionality

… ordering

Lists let us have a theoreticaly infinite number of extras registered, with no overflowing into the next stage

… to `Extra` ABC