New client-server architecture

Introduction
---------------
As discussed on #112 and #104 , pyqode 2.0 will need a brand new client-server architecture. I will quickly resume the issues and limitations we have with the current system, the goals of the new architecture and a brief preview of what the next api will look like.

Issues and limitations
---------------------------

- user cannot choose the interpreter to use to run the server code, this will cause problem if we switch to python3 for the code base as jedi, pyflask, pep8 are bound to the interpreter, we would lose the ability to support python2 syntax.
- the server is shared among QCodeEdit instances, this cause problems such as #102 because pickle is used to serialise data before sending through the socket.
- while the multiprocessing claims to supports cx_Freeze, its a pain to set it up. It would be way easier for us and for the user if he could write and freeze its own server script
- tools such as jedi does not work well when used from a frozen application because the interpreter does not have a complete standard lib,... This is very limitating, its impossible to use pyqode to create a frozen python IDE for windows. Adding the ability to select the interpreter would solve this.

Goals for the next design
--------------------------------

- allow user to select a custom interpreter
- simple api for selecting the worker to execute remotely
- get rid of pickle, json seems to be a very good replacement solution
- full support for python2 on the server side. This is a mandatory for all pyqode.core and pyqode.python workers. Other pyqode extensions for other languages don't really care about that and will probably use the defaul interpreter
- allow the user to write its own server script. Don't worry this will be very simple (1 line of code in the main function). That way you will have full control over the configuration of your server script
- 1 client-server pair per QCodeEdit instance

Solutions
------------
- server side will be implemented using the socketserver module and will use a json based messaging system with a simple ```header+payload``` protocol
- client side will be implemented using the QtNetwork module which fits nicely with a the gui event loop.
- use fully qualified name to defines the worker function/callable to execute remotely
- a request is identified by a uuid
- you can link a callaback with a request on client side to get notified when the results are available

Here is what the server script you will have to write will look like:

``` python
import sys
from pyqode.core.api import server
if __name__ == '__main__':
    import sys
    print("running with python %d.%d.%d" % (sys.version_info[:3]))
    # run the server
    server.run()
```

And here is what you will have to do with QCodeEdit to start the client-server pair:
```python
code_edit = QCodeEdit()
# run server with python2, the gui is a python3 script.
code_edit.start_server('path/to/my_server_script.py', '/usr/bin/python')
code_edit.open_file(...)
...
```

Status of this PR
----------------------

The client-server api is ready but has not been incorporated into QCodeEdit and the modes yet.