update #83

Storing it on the rosterview causes race conditions.

The RosterView view is now an overview of RosterGroup objects.

RosterGroup objects each have their own collection of contacts which fall under that group.
Additionally, the RosterView has a collection of all contacts.

The comparator of RosterContacts is now used to correctly position roster
contacts and we therefore no longer need to explicitly sort them afterwards.

updates #83
updates #151

This is because we can no longer assume a one to one mapping between roster
contacts and their views. Roster contacts can belong to more than one group,
each group needs to show the contact, which means we need a view for each group
the contact belongs to.

updates #83

In order to make group values non-distinct, (i.e. buddies can be in multiple
groups), we can't assume there's one view per roster item.

This means we cannot manage the rosterview as an overview (since it makes this
assumption).

updates #83

updates #83

updates #83

by moving event handers out

* Differentiate between adding new roster items and rendering existing ones.
* Also, only sort pending and requesting contacts once they've all been added
  (similar to what was already being done with existing contacts)

Simplified updateRoster by removing the duplicate checks that RosterItemView's
render method was doing.

Can't know whether existing roster item is already shown under the existing group.

But other user is not online to quickly subscribe back.

Conflicts:
	converse.js

Assignment to writable property `style.height` instead of readonly `offsetHeight`.

Fixes #196.