Move cython relict in madx.py to libmadx.pyx
Fix weird import bug

The last commit has created a weird import error, but only on python2.x
and only when installing with `python setup.py install` (as opposed to
`pip install .`).

Currently, I don't see any reason for this issue, especially since the
last commit was only a rename - I double checked that it was working on
the previous version.

Luckily, the issue is easy to fix.

In more detail: when performing `import cern.cpymad` an exception
occured with the following traceback:

    Traceback (most recent call last):
      File "test/cpymadtest/test_survey.py", line 2, in <module>
        from cern import cpymad
      File "build/bdist.linux-x86_64/egg/cern/cpymad/__init__.py", line 20, in <module>

      File "build/bdist.linux-x86_64/egg/cern/cpymad/model.py", line 35, in <module>
      File "build/bdist.linux-x86_64/egg/cern/madx.py", line 10, in <module>
      File "build/bdist.linux-x86_64/egg/cern/cpymad/madx.py", line 31, in <module>
    AttributeError: 'module' object has no attribute 'cpymad'
Use relative import statements in cpymad

From now on use relative import statements in the cpymad subfolder where
possible. I don't know if this makes anything better, but it looks
cleaner to me and the last commit fixed some weird bug with an absolute
import statement (possibly due to a circular reference?).
Add RPyC service

RPyC is an RPC library that uses proxy objects to facilitate
communication with a remote service. We can use it for communication
with the libmadx binding.
Rename class cpymad.madx.madx to cpymad.madx.Madx

The default python naming convention is to use CamelCase for class
names. For backward compatibility the name 'cern.madx.madx' is still
available (although I think it should be removed when splitting cpymad
and jpymad as this will be a major change anyway!).
Use the RPyC service in cpymad.madx to make instances independent

This effectively let's instances of the madx wrapper class act
independently, since they are now communicating with a remote backend.

This resolves #35 and partly #43.
Use cpymad.madx directly in cpymad.model

Since each cpymad.madx.Madx instance now represents one separate
instanciation of the MAD-X library, we can forget about the
multiprocessing wrapper in cpymad.model. The functionality of this part
is replaced by the RPyC service.

Fixes #3 (hopefully).
Fixes #43 for python>=2.7