Issue #750

I broke it in my interface-extraction shennanigans.

Closes DMDirc/Plugins#509

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

Stop swimming against the tide and accept what most of the rest of
the world does.

While it adds an annoying depth to the actual source code, it makes
the root directory nicer (no more 'test-res' dirs), means we don't
have to override the gradle config, and makes it nicer to work in
IDEA 2016.1.

Closes #662.

This allows windows to be uniquely identified and shared with
clients that are running outside of the DMDirc process (e.g.
a web UI, or a remote instance).

Migrate all users to using the InputModel.

Instead of WindowModel defining lots of methods on the off-chance
that the window is writable, pull them all into a separate
optional InputModel.

For ease of transition, FrameContainer will just implement both,
but eventually the input handling should be pulled out into
its own class.

Closes #426

Issue #426

With numeric formatting gone, all output is either added direct
to a window (which will be changed soon) or done through
displayable events. Message sinks are now completely unused,
as they don't affect displayable events.

Issue #426

This allows us to remove a fair chunk of the notification
handling functionality in FrameContainer.

Issue 426

I think these will eventually go away entirely, once everything
is event-bus'd, but I'm not entirely sure how that works any
more :(

Instead of passing them in to the FrameContainer ctor, create
them afterwards.

This means the reference in FrameContainer can't be final but
removes the horrible setOwner() kludge that was previously in
CommandParser, and cuts down the deps needed to pass in to the
FrameContainer ctor.

Think we're going to stop supporting this. If there's a decent
case for it then it should be done as a DisplayProperty instead.

From everywhere.

We now need it to exist independently of anything requesting it,
otherwise we miss lines being added.

Add defaults for the old colours instead of horrible lime green.

Drop the /notify command, as manually setting it doesn't make
sense in a post-actions world.

Drop the action component because they're now useless.

Should probably improve this to only raise an event when the
values change, but will do for now.

It doesn't really make sense in ui.core now it's doing more...
The classes it's integrating are all in messages.

Urgh.

This is where displayable events are going to be added.

This will move some of the logic out of FrameContainer, and will
be responsible for handling DisplayableEvents in the future.