If a contact is trusted or already likely to know our presence (due to having
sent them a message) then auto-fetch XHTML-IM inline images via XEP-0231 from them.

If we already have the image for the Cid downloaded, then do create the
thumbnail and show it inline.

Only supports images with XEP-0231 compatible cid: URIs, otherwise images render
as a fallback image.  This commit doesn't yet support fetching the images at
all, but can ask a passed-in thumbnailer to figure out getting the image for a
certain Cid.

The XML model that was being used was not able to represent elements with text
nodes and element children interspersed (such as in "markup like" XML:
<x>abc <y>def</y> ghi</x>).  This switches from a single content String to a
list of child Node.  Content is pulled from all children recursively.  A list of
Element children is also maintained since this list is frequently traversed so
it saves runtime checks in all of those loops at the expense of a small amount
of memory.  Since the children and childNode lists must be kept in sync, they
are both made private to avoid a child class trying to mutate one of them
without a safe helper.

Use the labels and icons from JMP onboarding, don't ask users if they want to
create an account on their "own server".

* recolour-bubbles:
  Fix shadow, add tails, fix monochrome
  Match theme colours
  Less bubbly
  Remove unused 9patch
  add the newly created color entries to the bubble Drawable
  add XML entries for sent/received bubbles
  remove hardcoded bubble color
  link all the old 9patch refereces to the new Drawables
  Tweak the chat page for the new bubbles
  forgot to commit the new bubble Shape Drawables
  link all message bubbles from all themes to the same XML drawable
  use the new msg bubble XML instead of the 9patch PNGs

Now editing the color from the theme affects the bubbles directly. Monochrome versions left to do still. Also added the Theme entries so the theme applies to the bubbles

This is the first feature to hardcode cheogram.com let's hope we can remove it
someday.

XEP-0033 does not have good fallback behaviour, and group text doesn't map well
to MUC.  We could still do a MUC mapping, or think of a better fallback
behaviour, or something else, but for now analysis paralysis means we stick to
the gross +1...,+1...,+1...@cheogram.com -- but that's not a protocol, it's not
something we can detect or design around or expect anyone else to ever do.  So
just check for cheogram.com because that's the only place we ever expect to see
this dirty hack.

If starting a new private group and every selected member is @cheogram.com, then
ask if we should make a group text instead.

For debugging call connections etc.

A body that is present but has an empty string is not the same as no body.  It
may be useful for example for a message correction to an empty string.

So if someone else sends one to the bare JID, we should deliver it to any
connection that matches.

* content-addressable:
  Content Addressable Media Storage