Support for arbitrary channel nomenclature

[kkappler]

See aurora issue#74 in aurora.

After some kerfungling, I have successfully mapped channel names on synthetic data using a dictionary and produced TFs from LEMI-like labelling on synthetic data.

The changes I had to make are on aurora branch issue_74. I did have to make some changes in mt_metadata as well, namely:
mt_metadata/transfer_functions/core.py
mt_metadata/transfer_functions/io/emtfxml/emtfxml.py

The changes are simply to replace, for example, the text strings "ex", "ey" with variables EX EY whose values can be anything.

An important question is : @kujaku11 Do you think that the TF class, and output xml should use the same nomenclature as the time series, or default to "ex", "ey", "hx", "hy", "hz"?
The way it works now, we use the default names in the xml.

The implementation is passing all tests and behaving itself.

A few things to look at:

• I used the concept of a naming_system variable with a string value. I had to add this property channel_nomenclature to the Processing config class in aurora. Not sure if we want it hanging around in mt_metadata?
  You can see some examples of naming system in the new module I added called
  mt_metadata/transfer_functions/channel_nomenclature.py. The idea is that if you ignore this you will get the default mapping:

DEFAULT_CHANNEL_MAP = {
    "hx": "hx",
    "hy": "hy",
    "hz": "hz",
    "ex": "ex",
    "ey": "ey",
}

• I implemented a channel map called LEMI12, which processes magentics and e1, and e2. Of course we could create a LEMI34, or even a LEMI23,

• I used some ALLCAPS in the implementation, happy to change that - PTAL the diffed files.

[kujaku11]

TF can have arbitrary channel names now and seems to work with Lemi and Phoenix nomenclature if e1, h1, .... Closing for now