Multiprocessing branch for u2py

+ Reader operations can now be executed in separate process
+ ReaderWrapper replaces Reader from the program point of view as a
context manager
interface.Reader fixes

+ Reader.sn should now return string instead of ByteArray instance
+ Obsolete comments removed
reader_detect+multiprocessing compatibility fix
master and multiprocessing compatibility fixes

+ handlers_base now uses code, that does the same indifferently to
underlying implementation
(classic or from new multiprocessing branch)
+ reader_pool.ReaderWrapper should now be compatible with Reader in
terms of apply, open and close functions
Now using multiprocessing.freeze_support

+ service.py now specifies python executable to use as u2.exe from the same folder.
Added new options to configurate

+ webapi.config.notifier_poll_timeout
+ webapi.config.error_with_traceback
Latest version of u2 with asio-mt implementation.
Test suite extended

+ Added service_test_version.py
+ Notification test integrated into test suite
+ Added few test to service_test_errors.py
Using Reader from another process implemented in ProcessReader

+ renamed reader_pool.py to process_reader.py and refactored names inside
+ with ProcessReader.apply its now possible to explicitly specify class to call
  (used in notify.py).
+ Remote worker process now analyzes config.py logging facility and deduces name of its own logfile.
Implemented custom Server class based on WSGIServer

+ Server.serve_forever now implements external reader process management at the beginning and at the end of program.
+ With this change, there is no need for custom process management code for u2.py or service.py
Fixed naming issues related to process_reader renaming
Reworked notification mechanism according to latest changes in architecture

+ Now using ProcessReader.apply to conform to program architecture.
+ Removed possibility of sudden dictionary change in the middle of iteration (introduced due to gevent greenlets mixed with gevent ThreadPool in the middle of iteration).
+ Notification format changed to json: { "reader": <number, reader_id>, "sn": <number, card serial number> }
asio-mt impl now default + reader_field_off no more
Now using asio-mt as default impl
Internal configuration fix
Reworked parse_post_data

Return value: (context manager, request dictionary)
  Request parsing, argument presence check and context deducing are done here.
  Parsing: json.loads with JsonError when there is no data to parse or given
 data is not a json.
  Argument check: if |args| parameter is not None, then we assume it contains
 an instance of Args class with overloaded __contains__ method and 2 attributes:
 |required| and |defaults| that specify list of parameter names which are essential
 or optional for this method respectively. MissingParameterError will be raised
 when there is no essential paramter present in request.
  Context deducing. There are 2 types of context: reader and readerless.
 Reader context.
 Any api call that requires exactly one reader and doesn't interferes
 with others during its work should specify |reader| parameter as non-default
 within its argument list. Then, if |reader| key is present among request keys
 appropriate reader from |readers| should be returned as context manager for this
 request. Methods must be aware of the fact they'll be executed in another
 process should they conform to its requirements. There are methods which explicitly
 avoid being executed in another process despite accepting |reader| argument
 due to their purpose (e.g. /api/scan/notify). They do it by discarding |reader|
 from argument list and accept it from keyword arguments of its call.
 Some api calls behave differently according to the presence of |reader| key
 in request (e.g. /api/version). Specifically for them, None value of |reader| key
 is identical to the absence of |reader| key.
 Readerless context.
 When conditions of using reader context aren't met, readerless context comes to
 the rescue. As its name suggests, it doesn't belong to any specific reader
 and thus executes in the same process. "Doesn't belong to any specific reader"
 doesn't means it cannot work with any reader at all - it's just says that api call
 performs some general work that cannot be identified with only one reader and thus
 shouldn't be redirected to reader process. (notifications and reader detection
 are examples of such work).

+ APIEncoder replaced with explicit specifying of default function
Version 1.6.1

+ Documentation added
+ Reader reopening on IO_ERROR can now be configured via u2py.config.reopen_on_io_error
staff.py now uses method='full' to read data from card
Sector.write_block now behaves correctly with any sector method.
Added exception catch when executing library calls.