Add layout to settings activity

Format the form in a `TableLayout` and put it inside a `LinearLayout`.

.. note::
    `EditText` views have a minimum size (~200dip?), which make them wider than
    the screen when aligned to the widest `TextView`. Doesn't hurt much
    (rightmost character when scrolling in field may be cut), but isn't awesome
    either.
Comply with XMPP login proto

XMPP requires a client to send its presence and to request its roster upon
login.

Smack can do this implicitly. The feature can be controlled with
`ConnectionConfiguration.setSendPresence(boolean)` and
`ConnectionConfiguration.setRosterLoadedAtLogin(boolean)`.
Both values default to `true`.

This commit removes superfluous calls.
Merge branch 'xmpp_service' into roster
Include groups in contacts

So far the result of `getContacts()` was a plain list of contact names. In this
data structure the information on which group a contact belongs to was lost.

This commit introduces a `Map<String, List<String>>` as the return type of
`getContacts()`. The keys are the groups of the roster and the values are lists
of user names contained in that group.
Extend XMPP interface

So far the `IXMPPService` interface only contained methods for registering
update recipients.

This commit adds the other methods to the interface and renames groups into
rooms (since groups are now part of the roster).

Maybe the semantic term of what we formerly called `groups` should rather be
`team`?
Introduce `RosterActivity`

Add draft of a `ExpandableListView`.

.. note ::
    The creation of the activity still dies with a `NullPointerException` when
    it tries to access its `XMPPService` instance.
    The service gets bound successfully (although clumsily), but
    `onServiceConnected()` of the service connection doesn't get called.
Merge pull request #21 from 0x64746b/xmpp_service

Xmpp service
added destroyGroup() function to XMPPService

destroyGroup() tries to remove the room from the server.
also placed removal of a group from the group list in an own function.
Fix `NullPointerException` in `RosterActivity`

`onServiceConnected()` in the service connection is called asynchronously.
That's why you can't rely on the service being set when `bindService` returns
`true`.

This commit moves the code fetching the contacts from the `XMPPService` and the
filling of the expandable list into `onServiceConnected()`.
Merge pull request #20 from 0x64746b/settings_layout

Settings layout
Merge branch 'xmpp_service' into roster

Conflicts:
	android/src/de/teammeet/xmpp/XMPPService.java
`getRoster()` from `XMPPService`

So far `getContacts()` was used to get a predigested list of contacts from the
roster.

Since the roster provides way more information than contact strings (e.g status
information, the ability to manage groups and contacts, ...), this commit
makes the `XMPPService` provide the raw roster which the `RosterActivity` uses
to fill an expandable list.

This eliminates the intermediate step of parsing the group and contact strings
from the roster that later need to be reworked into the very specific data
structures required by the `ExpandableListAdapter`.
Add presence information to `RosterActivity`

So far this is retrieved only once when the expandable list is filled. No
updates or even notifications yet.

If we decide to display availability differently,, the first main line might
show a contact's name while the second displays its full jid.
Create local list adapter

So far the variable holding the `ExpandableListAdapter` was a member.

This commit turns it into a local variable.
Handle unfiled contacts

So far only contacts contained in groups were listed.

This commit introduces an inner class `ExpandableContactEntry` that encapsulates
the creation of data structures suitable for passing to the
`ExpandableListAdapter`.

That makes it easy to create another group containing the unfiled contacts.
Introduce `RosterListener`

Changes in presence are recognized. It is possible to find out which contact
sent the presence package and into which group that contact belongs.

It may be unfeasible though to retrieve the relative position of its group and
of itself within that group, which would be necessary to access the
corresponding child in the `ExpandableListAdapter` in order to update it.

It might be easier to rebuild the whole expandable list if a change in the
roster is detected.
Update random entry in `ExpandableListAdapter`

If we calculate the positions of the updated entry in the adapter, it is
possible to update the value. Although with the current code the list turns
unresponsive and redraws are only issued when triggered by pressing the menu
button.

Currently I tend to just rebuild the whole expandable list.
Merge pull request #23 from 0x64746b/roster_activity

Roster activity
seperate maps api key from layout
use strings from strings.xml in settings layout