We have a good number of i18n strings which contain HTML, and it'd be
very useful to continue supporting that. However, it's difficult with
React: in order to embed raw HTML into JSX, you have to use a prop
called `dangerouslySetInnerHTML`. That's not a nice API to use
everywhere we want to display a simple string. Well, say we wrote a
small helper utility that used `dangerouslySetInnerHTML` for us. This
also wouldn't work out well: you can only use `dangerouslySetInnerHTML`
on an actual element, so we'd have to embed many, many strings in a
useless <span />. Yuck.

Clearly, we need a way to parse HTML in our strings and convert them
into React elements. There's no way around that. The new `expand`
implementation (a simple recursive-descent parser) does that.

There are some "breaking" changes in the new implementation:

  1. You can no longer interpolate raw HTML into a string; it has to be
     a React element. All string values will be HTML-escaped by React.

  2. Only a safe subset of HTML is supported.

  3. An (apparently unused) feature of the link substitution syntax was
     removed. Previously, if you had "{foo|bar}" and `bar` was a key in
     the substitution args, it would use the value at that key as the
     link content. This has been removed because it doesn't appear to be
     used, and it makes it ambiguous or difficult to determine if `bar`
     is a key or a text string in some cases. You now have to be
     explicit and use "{foo|{bar}}". This method was already supported
     and used.

The new function is now used in place of the old one whenever `__react`
is set in the substitution args. The old "expand to array" behavior of
the old function has thus been removed.