Implemented support for custom opt types

Motivation:

Currently oslo.config supports only basic set of types:
strings, integers, floats, booleans, lists of strings and
dictionaries of strings. The reason of existence of types
other than string is to provide some kind of value
validation (e.g. that integer contains only digits).
There is a demand in community to have more complex value
checks, e.g. that a port configuration option contains
integer value that fits in certain range, host ip address
conforms to ip address format, etc.

Solution:

This patch introduces support for custom Opt types that
will allow a better control of value conversion and
validation. Custom types are presented as type
constructors - callable objects that take a string and
either return converted value or raise ValueError in
case value can't be converted. This concept is similar to
argument types in 'argparse' library.
Type constructor can be a class which instances are
callable, a function or any callable object (which allows
usage of parametriezed type class instances).

Details:

Oslo.config has Opt subclasses that control value
conversion and validation: StrOpt, IntOpt, FloatOpt, etc.
The type information is added to the base class - Opt -
cause otherwise it would introduce confusion on what class
to use when introducing e.g. NetworkPort: StrOpt or IntOpt.
For each existing Opt subclass a corresponding type was
implemented (see oslo.config.types).  StrOpt, IntOpt, etc.
classes are left for backward compatibility and present an
Opt class parametrized with particular type.

There are two exceptions of this rule: BoolOpt and
MultiStrOpt. Those classes define a special logic for
parsing values. BoolOpt was left unchanged and should be
used when someone wants a Boolean option that is available
through CLI.
MultiStrOpt has logic to accumulate values. As it was bound
to String type only, it's logic was extracted into a
MultiOpt class and MultiStrOpt was left as a subclass
parametrized with String type.

Opt values allow value substitution. Previously it worked
only for string types but now this feature only makes sense
if it would work on any type. _substitute() and _do_get()
methods of ConfigOpts class were updated to cover that.
Also, TemplateSubstitution tests were updated to ensure
that substitution is done before type conversion kicks in
or otherwise type conversion will fail (e.g. if Integer
type converted will get something like '$listen_port').

Advised review steps:

1. New type classes (oslo/config/types.py) and their tests
   (tests/test_types.py);
2. Changes to Str/Bool/Int/etc-Opt classes
   (those are pretty straight forward);
3. Other changes that add support for new types into
   existing infrastructure;
4. New cfg test cases added (mostly related to changes in
   substitution mechanics).

blueprint oslo-config-options-validation

Change-Id: I6910f1efa540cfe757b2be6da0aec072f8ed28fa
Merge "Implemented support for custom opt types"