Async friendly ObjectServer

Before being able to provide async service API (the last item on #37 (closed)), we need to make the ObjectServer+Interface async friendly. The main problem here is the use of TLS. While there are task-local APIs out there, they are runtime specific and hence not useful for us. So we need to remove these TLS. The challenge there is to provide an intuitive and simple API for signal emission still. I and @danieldg discussed this a bit and we though of some ideas. I'm documenting them here so we can discuss and then implement them:

1. simplest:
   1. addition of more special args to dbus_interface so methods can optionally receive path (which they can already access with the header arg) and connection (already have a patch for this one).
   2. generating emit_<signal_name> methods for each signal that takes a path and connection as args, in addition to the args declared by the user.
2. Same as #1 but instead of separate args, we add a new opaque type (let's says SignalEmitter or SignalContext) that contains the path and connection refs. Then the signal declarations (from the user) and the method dbus_interface generates for them remain the same as they're today but take SignalEmitter as the first argument (instead of &self).
3. This also involves a SignalEmitter type (or ActiveInterface as @danieldg put it) but instead of us creating and passing it to the user's methods, they provide a way to get access to this for their interface (e.g by implementing AsRef<ActiveInterface> for their type. We could provide macro support for adding such a field/variant to their type easily and implementing AsRef<ActiveInterface> as well.

There were other ideas too but I think we should first focus on these. Personally, #2 seems the best and nicely combines 1 and 3. Feel free to propose other ideas but given that users love our current API/macros, it'd be best to not deviate too much from it in 2.0.