We now specify the default colour using display properties, not
by ascribing special value to the first colour code in a message.

Closes #741

Issue #750

Issue #750

Issue #750

Closes #755

This won't affect normal use of the client, other than it having
a few extra unused classes and some additional lines in the
manifest.

Issue #750

Closes #757

Closes #751

If an object in a formatter tag ({{foo.bar.baz}}) is Displayable,
then we will modify the output based on its display properties.

Currently only supports user links and foreground colours.

This also changes the internal format of nickname links to be
`\u16<nick to link to>\u16<text to show>\u16`, allowing the
link and text to differ. This means if you formatted users
by showing their realname, you could still click them to
open a query.

Closes #424
Closes DMDirc/Plugins#507

Issue #424

I broke it in my interface-extraction shennanigans.

Closes DMDirc/Plugins#509

Make it extend a list instead of wrapping it, so we can just replace
all usages with... an actual list.

Flip BaseCommand and Command around so everything still works.

Command will eventually become an interface when all usages have been replaced

The styliser needs an interface extracting into the API, and
we don't really want huge static methods defined on that.

At present anything requesting the global config has to depend on
ClientModule, which won't necessarily be exposed through the API.

Move @GlobalConfig, @AddonConfig and @UserConfig to top level
classes in API, and provide both versions of them for now.

Some other minor tidying to Styliser.

Rename the private implementation to ConfigBinderImpl, and
make ConfigBinder itself an interface.

This shouldn't be exposed. Internal classes switch to using
the full class rather than the interface, so they can carry
on accessing the removed methods.