Support editing arbitrary precisions for GlobeCoordinates

Bug 65535.
Non-custom values are numbers or strings. It's like this:

Listrotators are initialized with an array of name/value pairs. These are the non-custom values which are always shown. Setting the rotator to one of these values is trivial using `.value` and `._setValue`. On the other hand, our experts need to be able to set the Listrotator to a value which is not in this initial list (a ›custom‹ value). This is done by injecting a name/value pair into the Listrotator and then calling `.value` and `._setValue`.

This module here (the ExpertExtender's Listrotator extension) wraps the ugly injection and handles cleaning up. In order to do that, it has to recognize a given value as either custom or not. It could also just try to find it in the Listrotator's value array, but that would be uglier, slower and more error-prone. So the expert has to explicitly say that a value it passes is not just a pre-configured value from the Listrotator's config, but indeed something new and custom. That's done via the `custom` property, and it also needs to pass a name and a value, because the Listrotator obviously needs a name and a value.

The only thing I can imagine we could change without rewriting a lot of Listrotator (which I tried to avoid with this patch) is changing the signature of the `getUpstreamValue` argument of `ExpertExtender.Listrotator` to always return an object, either `{ value: 'normal value' }` or `{ value: 'custom value', label: 'label for custom value', custom: true }`. I don't see much of an advantage doing that, though.