* bob1:
  Preliminary support for bits-of-binary

https://xmpp.org/extensions/xep-0231.html

When a CID URI is received as part of an OOB, use bob to fetch from the sender.

This does not verify the hash at this time, nor does it "cache" for a future
send since our storage is not content-addressable yet.

* commands: (50 commits)
  Tell the server we have a UI that can handle up to 1000 items
  For very long lists, use a searchable list view
  Use a list item background that can handle being selected
  Allow nested scrolling of ListView and WebView
  NPE
  Show any commands pushed along with a message
  Allow oob webview to move the execution forward
  Spinner when loading list of commands
  Show spinner when loading if it takes awhile
  Menu item to refresh features for a contact
  Order cells by reported order
  Look more like a real web browser
  Don't submit the form when cancelling
  We can still proceed with no form, just don't send a form
  Validate presence of required fields
  DRY up common patterns for fields
  Refactor to bind to an Item container, not just a raw Element
  Use more features of the TextInputLayout
  Support more text field types
  Support reported/item tables
  ...

Shouldn't be needed in general, so hidden under a sub-menu, but for advanced use
cases and especially services without caps, can enable features that normally
would not be detected.

Instead of assuming all items are in the same order as reported

It's at best a waste of bytes and at worst confusing to the server.

Gets rid of the Column extends Element hack and paves the way for error messages
and other things.

Right now renders using a GridLayout which means all columns are the same width.
No horizontal scrolling or becoming not-a-table for many columns, so big tables
will be a disaster.  Does render and work though.

The strategy here is to actually make each cell an "item" in the RecyclerView
instead of each row being an item.  Then the layout manager takes care of it.
This means that the end-of-row-ness is just because of column count, and not
actually enforced at all.  It also means that as currently built if any row has
a missing field it'll mess up the whole thing.

No type directed rendering or anything yet, just dump it out.

These don't make any sense to send to us, but in practise biboumi does and
expects us to ignore it.

Spec says that actions must be specified if there are any.  In practise, at
least biboumi violates this and sends back no actions at all but is in
"executing" state meaning it expects a next stage.  So in this case we should do
something smarter than assuming we're all done.  Put up a button for the
execute/default action.

And really hide it, even swipe should not work to get to the blank page

Otherwise it gets confused and blanks itself out.

If status is completed or canceled and there are no children, then there's
nothing more to say so just remove the session.

Instead of a single "done" button, show all available actions in the footer,
each in a different color (generated the same as avatar backgrounds, etc) with
the action name translated if a translation is available.

The pseudo-action "close" is for when a command is already completed.  In this
case, the execute() call will see that the session is already completed and it
will be removed without actually checking the action string at all.

The RecyclerView doesn't put consistent space between our elements, so we need
to make sure to but consistent bottom padding on them.

Depending on the fragment lifecycle, onCreateView and onStart may both be called
before the backend is connected, and so there will be no conversation yet.
Instead, do the conversation-needing initialization here in reInit where we know
we have it.

Does not handle reported/item tables yet, or fillable forms.

Otherwise assume the single item can handle scrolling itself.  Otherwise
single-item view with a scrollable child breaks.

The first element that we support. In this case, the first note.