Support separation of Thing and servers and fix the correct meaning of EventLoop

[VigneshVSV]

Something that was overlooked and made wrongly while trying to create the correct interface for properties, actions and events;
Generally the additions of endpoints (HTTP) or available resources (ZMQ) to the server is done in a server object.

This is not the pattern in this package, but must be supported soon so that the usage of different components are clear. This is especially true for the HTTP server as the URL and the request methods mapping are additional features of this protocol, compared to ZMQ which can simply serve an object based on the name of the object members.

Possible tasks

• define how HTTP server will accept endpoints from Things when they work over all three of IPC, TCP and INPROC ZMQ transports. Specifically it is meant that if the Thing is running over INPROC or IPC, we can still import the local object to add its properties, actions and events. However, for TCP the object may be running somewhere else. Nevertheless, implement this add least for IPC and INPROC.
• add to HTTP server
  • add_property
  • add_action
  • add_event
  • also accepting Thing object directly
    it should accept URL, HTTP methods as part of a tuple. For example:

server = HTTPServer()
server.add_action('/some-action', 'PUT', Thing.some_action)

• addition of objects to servers should also be support by ZMQ servers. Reason - Currently we do that with EventLoop object, which is the cause of the mistake. Technically, a server may serve one or more objects. The event loop only executes them. Further, the server holds the address that is to be connected by the client. Since we made server address thing instance specific, therefore for each instantiated thing, a new address is necessary, which is mildly contradictory.
• The way client finds the server may also need adjustment

This code : https://github.com/labthings/python-labthings may serve as reference. See last 10 lines of the example.