When receiving a PreKeySignalMessage, then a prekey has been chosen and
should now be removed from the list of available prekeys in the bundle,
so that a different device doesn't choose it as well.

AFAICT, libsignal removes the prekey, so it's then up to us to
regenerate it and republish our bundle.

updates #497

Before these changes, prekeys were stored in two places, one place that
converse-omemo accessed and one that libsignal accessed and when
libsignal deleted a prekey the other store wasn't updated.

Now we let the methods called by libsignal store/remove prekeys (and the
signed_prekey) in the same place as used by the code in converse-omemo.

updates #497

updates #497

Updates #497

Updates #497

updates #497

updates #497

Array Buffers can't be JSON serialized as is.

updates #497

updates #497

updates #497

updates #497

Instead of setting `active` to `false`, we remove the device entirely
(unless its the current device).

Doing it this way means more fetching of bundles for devices that
disappear and then reappear from a user's devicelist.

However, there might be caching invalidation concerns with just reusing
a cached bundle for a device id that disappeared and then reappears.

Additionally this change simplifies the showing of a contact's device
fingerprints in the modal, since we don't have to take active/inactive
into consideration.

updates #497

The `_converse.session` store gets cleared after logout, but we want the
`trusted` flag to persist after logout.

Also update the documentation no that the `storage` config option has
been removed in favor of `trusted`.

Setting it on the model itself is not sufficient and then causes
changes which should be type `update` become type `create`, causing
multiple versions of the model... resulting in chaos.

So that it persists across page loads. Otherwise storage falls back to
the default, causing records to be in both local- and sessionStorage.

Additionally, update singleton models to have the 'id' available as a getter.

Otherwise multiple records gets stored in browserStorage, causing random
results being returned.

Otherwise the collection's items aren't fetched but it's own properties.
The way to persistently remove items from a collection is to destroy
them, NOT to call `remove`.

Based on live testing. Updated tests accordingly.

- Use sizzle xmlns selector (which doesn't work with `querySelector`)
- PEP Subscription didn't have `+` before `notify`