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.

This allows running DMDirc from IDEA, which seems useful.

Running a normal build just replaces the file in the build output.

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.

Mockito now errors if a mock is unnecessary, plus a few other minor
API changes.

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.

This is just an IntelliJ refactor, using EventBus in place of
DMDircMBassador whenever possible.

Our API shouldn't depend on MBassador. Extract a simple interface
to break the dependency.

This is for the interfaces/trivial implementation classes that
DMDirc plugins can interact with. Eventually plugins will build
against the API instead of the DMDirc client itself, which will
allow for remote/detachable clients (amongst other things).

Issue #76

If the user doesn't specify a port, allow the parser implementation
to figure it out for itself. This allows for things like SRV lookups,
or different default ports per protocol.

For some reason this was only exposed through the WindowManager
listeners.