Create es-BO.

Also fix the availableTranslations lookup/fallback logic to be more
accomodating of optional country suffixes.

Fixes: #1010
Clarify tracker vs trackerName.

Try to make it clear in the code when we are passing around the *name* of
a tracker (a string) and when we have an actual tracker object.
Clarify element vs elementPath.

Try to make it clear in the code when we are passing around a jquery
wrapper of the actual DOM element, and when we are passing around
a path specification for that element (a string).
Add `setHistory`/`getHistory`/`getValue` helpers for trackers.

The `setHistory`/`getHistory` methods allow trackers to define their own
methods to store/set history for a tracker.  The `getValue` helper is
extended to call `tracker.getContent` where appropriate.
Pass `sendData` to trackers; allow `maybeSendUpdate` override.

Allow trackers to define their own implementation of `maybeSendUpdate`
(in particular, if they would like to use a different format for their
update messages).  Pass the `sendData` method to the tracker constructor,
so that trackers outside of togetherjs core can use the same techniques
which the built-in trackers use.
Factor out `{make,serialize,parse}Delta` functions.

This allows trackers to use their own representation of "changes" while
sharing the basic `ot.SimpleHistory` framework.
Refactor tracker init/makeInit methods to reuse common code.

Trackers no longer need to define `init` and `makeInit` methods if they
define a `getContent` method and can reuse the standard ot mechanism.
Custom trackers may define a `makeInit` method to override the built-in
history mechanism.  They can also define `parseInitValue` and
`serializeInitValue` methods if their `getContent` method returns
a complex object which is not immediately serializable.
Better handle race conditions during form initialization.

Add a server-generated timestamp to the `init-connection` message, and use
this to identify the "oldest session" when arbitrating between multiple
received `form-init` messages.  Also defer updates between the time
that `form-init` is sent and when it is received echoed back from the
hub, in order to ensure that the newly-inited peer does not start up
with stale state.
Multiple hellos from the same client shouldn't confuse form init.

Improve the form-initialization algorithm introduced in
eb6519ea9cb144b01cec51933dd6fb6d0380f1a1 by adding a unique identifier
to the `hello` message to ensure we don't get confused if we get
multiple `hello` messages from the same client in quick succession
(as we might, for example, if the user double-clicked "reload" in their
browser).