Port the library to use View-subclasses?

So I believe it would be more Atom-centric to base this library on the `View`-classes in Atom, and rely on their `content`-DSL for building up the interface.

I also believe that it would be more extendable if the panel-class itself didn't contain the functionality for rendering specific types of messages, because that makes it harder to extend. So there is now a panel-class (`MessagePanelView`) that is a container of messages. There are currently two such messages, `PlainMessageView` and `LineMessageView`, that corresponds to the two types of messages that was previously supported.

This is of course a complete re-write of your library, so I don't necessarily expect to accept this request. But I thought it was a valuable discussion to have - if you want this library to move towards a more Atom-centric way, or not?

An example of how you would use it is:

	var MessagePanelView = require('./atom-message-panel').MessagePanelView
	  , PlainMessageView = require('./atom-message-panel').PlainMessageView
	  , LineMessageView = require('./atom-message-panel').LineMessageView
	
	var messages = new MessagePanelView({title: 'Test pane'})
	messages.attach()
	
	messages.add(new LineMessageView({line: 1, character: 5, message: 'Line messages', preview: 'With <i>pre&amp;views!</i>', className: 'text-error'}))
	messages.add(new PlainMessageView({message: 'Oh yeah!', className: 'text-error'}))

---

The only thing that currently isn't supported is the line-indications. But I do sort of think that it's a bit weird that a message-panel should be responsible for modifying the gutter of the current editor.
However, something similar could be added to the `LineMessageView`-class such that it adds a class-name to the line it corresponds to.

Anyways, let's have a discussion of pros/cons of the two approaches. Personally I like the OOP'y nature of my approach and the how easy it would be to add other types of messages to the panel.

Kind regards
Morten.