After data binding with IronMeta was lost in 0.8, we needed a way to bind the
same data in multiple places, especially data relating to a complicated model:
lots of pages might want to show or change this data, but only one element
should be responsible for complex logic for responding to model changes.
Biggest example was Preferences.

Two options were:
1. Have one element at the top of the tree handling the model and providing the
   data. Normal data binding propagates changes up and down the tree -- the
   downside is, you have to declare properties in every node in between the
   elements you want to share data.
2. Replace IronMeta with a Singleton/Observer pattern. Create the singleton
   element at startup; it owns the data. Any element that wants to bind to
   that data adds an observer element to its local DOM and binds to that --
   no dependencies on ancestors or descendants.

I implemented option 1 for Preferences and Languages, both very complicated
models that can't just be a Behavior shared by a bunch of elements. In
hindsight, the implementation is too obscure, fragile, and (possibly) less
efficient than plain old data binding. There's extra code for managing the
Observer relationships, and there are singleton elements created at startup
that could be created later. Furthermore, it would be a burden for anyone
other than myself to get up to speed on and maintain in the future.

I want to remove settings-languages-singleton and settings-prefs-singleton.
Languages data binding is easy because, unsurprisingly, everything that uses
the languages model is a descendant of the Languages page. Prefs is easy
because we mostly already do it the normal way -- the Languages singleton
is the only other user of the Prefs singleton, which is a pretty good sign
that the pattern wasn't useful.

Original design doc for context: https://docs.google.com/document/d/1yTA34r7KyFXMlXxkSsR2vSNzh6V1S8MuxOrkh5smKaI
The nail in the coffin is that we never came up with other use cases:
other complex models live in the browser process, and are handled from
JS with simple FooBrowserProxy classes.