Split instantiation/config steps for the REST-ish server

Instead of providing a monolithic omni.omnid.main which instantiates OMNI
and then creates a WSGI server using wsgiref.simple_server, add a number
of functions in omni.app:

- omni.app.load_config: Load a configuration file.
- omni.app.make_application: Instantiates an omni.store.OMNI instance and
  configures it with the stores and realms defined in a configuration file.
- omni.app.make_wsgi_application: Makes a WSGI application out of an
  omni.store.OMNI instance, or of a configuration file. If a string is
  passed it is assummed to be the path to a configuration file, which is
  loaded using omni.app.load_config().
- omni.app.uwsgi_application (instance of omni.app.uWSGIApplication) allows
  to directly run the OMNI REST-ish server with uwsgi, and passing the path
  to the configuration file from uwsgi using the "omni_config_file"
  placeholder.

This new infrastructure allows to create a WSGI application without ever
running it under any server. In turn, this allows to e.g. create a WSGI
application, and run it under asyncio (via aiowsgi), and reuse the same
omni.store.OMNI instance to attach other services in the future in the same
asyncio event loop (for example: serving LDAP protocol).
Bring back creating omnid using entry_points

Using "entry_points" with distutils is better than using "scripts", as the
later does not take into account Python versions and other mishaps. Also,
rewrite the setup.py file so it can be imported as a module to debug the
Metadata class.