Inject LabelLookup got use by Formatters.

This allows the LabelLookup used by ValueFormatters to be
overwritten via the FormatterOptions. The idea is that
under some cirsumstances, the code creating a formatter via
a factory function may want to override otherwise application-
scope services, like the LabelLookup.

Point in case is providing an EntityInfoLabelLookup that makes
use of pre-fetched labels, providing a performance boost over
the default behaviour of looking up each label individually
in the database.

The rationale for using the amorphous FormatterObect for
injecting a context specific service is as follows:

* The use-case code knows that it can provide a "specialized"
version of some servies used by some formatters. It does not
know which formatters.

* The factory that creates the ValueFormatter (e.g. the
factory functions provided by WikibaseValueFormatterBuilders)
knows which ValueFormatter can make use of which service.

* The use-case code may not create or access value formatters
directly, but create and use higher level formatters, such as
SnakFormatters or an ClaimHtmlGenerator.

* Factories for the higher level formatters, e.g. the functions
provided by WikibaseSnakFormatterBuilders, should not know or
care about what services can be injected into which formatter,
and how.

* Thus, we need a mechanism for passing the specialized service
instances provided by the use-case-level code to the low-level
ValueFormatter factories, without requireing the intermediate,
higher level factories to know about such services (or other
options the low level formatters may use).

* An amorphous container for arbitrary services appears to be
the simplest mechanism. Re-using the FormatterOptions object
that is already used to convey options such as the user
language to the ValueFormatters seems to be the obvious choice.
This can be done with minimal additional code, and without
adding unneccessary dependencies.

Change-Id: I3c6ead36f501d61e7627722aea5f93b42574d7a4