first iteration towards element access through memory
test script..
Bootstrap setup.py: resolve dependency to numpy

With setuptools the `setup_requires` parameter can be used to install
missing dependencies before executing a build command. By subclassing
the build_ext command, the numpy headers can be added dynamically when
the numpy dependency is already installed.
Remove requirements.txt file

The file was previously used to install missing build time dependencies.
This has now become unnecessary:

- Cython is not a build-time dependency for the source distribution
  anymore (see 4bd9db9)
- With the previous commit, numpy will be installed during setup before
  the build_ext command needs it.
Simplify include/library path discovery

Note that this introduces a *minor* incompatibility when invoking
setup.py: The '--madxdir' argument can be given only once. Passing it
multiple times is now considered an error (which one should we take?).

If library and headers reside in different locations, you should use

    python setup.py build_ext -L<library-dirs> -I<include-dirs>

to specify them manually.
Remove automatic MAD-X discovery from setup

setuptools should be able to automatically find and use a system wide
installation. For custom installations, '--madxdir=...' can always be
used.
Update changelog
Fix new .travis.yml file and clarify wording
Fix the numpy import problem
Simplify libmadx.get_table return signature
Merge branch 'remote-exception-traceback' into simplify-libmadx-gettable
Fix str.split in libmadx._split_header_line

str.split expects the 'maxsplit' parameter as its *second* *non-keyword*
argument.
Fix regression: table name needs to be encoded

On python3 str and bytes are different objects and we need bytes to
communicate with the C API.
Merge branch 'master' into memaccess_elements
Update Madx.get_element (not using RPyC in master)
Merge branch 'master' into bootstrap-setup

Conflicts:
	CHANGES.rst
	setup.py
Use custom --madxdir for builds on test servers
Enable sharing connections to remote process

The Madx object shouldn't assume to be the sole owner of the
LibMadxClient connection. I will add a Sequence type soon, that also
needs to talk to the remote process.

The LibMadxClient object will automatically close the connection when it
is garbage collected. Since there are no cyclic references in the RPC
code (I believe), the finalization will occur at the same time that the
last object using the connection is finalized, which is optimal.

Closing the connection implicitly has one further upside: we can pass
any libmadx object in the constructor without assuming that there is a
connection object supporting it. This means, if you feel that talking to
a remote process is too much overhead, you can do the following:

    import libmadx
    m = Madx(libmadx=libmadx)

which will make the Madx object directly use the libmadx module.
Perform some cleanup in libmadx.pxd

- for simplicity list only the struct members that are needed
- for maintainability list the struct members in the correct order
- for explicity always use the most specific header file name
- for consistency use common spacing for pointer types
Extend/change API to retrieve sequence information

NOTE: the `libmadx.get_sequences` function now has a different return
signature, it just returns the list of sequence names, which is much
simpler than beforehand. More information about individual sequences can
be recovered with additional functions.

The `Madx.get_sequences` has also changed. It now returns a list of
Sequence instances. These objects can be used to lazily obtain further
information if desired.

Furthermore, adding a convenience property Madx.sequence to get/set the
name of the active sequence.