Partial implementation of contexts: a new feature to simplify common conversions

This commit implements contexts as a way to allow conversion between two unrelated
dimensions (e.g. time and length). contexts are specified by the source and
destination dimensions and the conversion function. These functions are used
in case

The context is implemented as a graph (not just isolated pairs) to enable
conversion from A -> C, if A -> B and B -> are defined.

Still to be done:
- a proper API to define contexts
- parsing of context in the defintion file
- default context
- parameterized contexts

See Issue #65
Proper handling of @import directive inside a file read using pkg_resources

load_definitions() takes a new parameter to indicate if the file was loaded
from as a pkg_resource. In that case, related files will be opened in the
same way.

See #68 and ufo-kit/concert#94
Fix get_dimensionality for non multiplicative units and provides test cases

close #66
Merge branch 'master' into develop
Fix get_dimensionality
Merge branch 'master' into develop
Context compatibility for 2.7 to 3.4
Implemented parameterized contexts

Transformation functions can include additional keyword arguments
to specify parameters. The values for these parameters can be specified
as default values for the context or given when entering the context.

See Issue #65
Updated CHANGES
Preparing release 0.3.2
Back to development: 0.4
Updated CHANGES
Preparing release 0.3.2
Back to development: 0.4
Parsing contexts from a string.

A context definition starts with `@context` followed by
the name. Relationships between dimensions are specified
one per line. Left hand side of the equal sign is used to
indicate which dimensions are related. A single arrow (`->`)
is used to indicate a unidirectional relationship. A double
arrow (`<->`) is used to indicate a bidirectional relationship

To the right, the equation is given using value as the variable name.

For example:

@context spectral
    [time] <-> 1 / [length] = c / value

Parameters and aliases can be given in the header.

@context(n=1) spectra = sp

Still to be done:
- a proper API to define contexts in the registry.
- the way to signal end of a context in the defintion file.
Merge branch 'master' into develop
Refactored context code to a new file
API to add, remove, enable and disable contexts in the UnitRegistry

- `add_context` and `remove_context` are used to store a context
  within the registry which can then be used by name or alias.
- `enable_contexts` and `disable_contexts` are used to make one or more
  context part of the unit conversion resolution path.

See Issue #65
Keep a reference to an inserted context object (not just its map) in ContextChain

This prevents garbage collection of temporary contexts created to change
the variable values.
Transforming values using contexts defined in strings

- `UnitRegisty.parse_expression` now takes keyword arguments that are used as
  locals() in eval.
  Names found in keyword arguments take precedence over units defined in the
  registry.
- The transformation function now takes keyword arguments that are passed
  to `UnitRegistry.parse_expression`. This keyword arguments are filled with
  the context values.

See Issue #65