The MI operation cancel/close calls are asynchronuous for async
subscriptions. The issue is that we're not waiting for those
operations to complete when tearing down event watchers.

For this reason, we may get event callbacks after deallocating
those objects, which will lead to invalid memory access and
crashes.

This can be avoided by waiting for the MI operations to be canceled
before going further with the teardown. After MI operations are
canceled, a cancel notification is emitted and the "more_results"
is set to False. We'll just wait for that.

If the _Connection object gets cleaned up before the event watcher,
MI crashes. This happens even if the _Connection destructor closes
the event watcher.

It's difficult to say what exactly MI is trying to access from the
crash dump alone.

One workaround is to avoid using weak references for the connection
object. This basically means that we have a circular dependency as the
connection object holds a reference to the event watcher callback.
This dependency gets cleared when calling the watcher .close method,
allowing the two objects to be cleaned up.

In short, with or without this patch, the watcher .close method
must be called when we're done with it (unless we're running a
daemon). Without this patch, if this call is omitted, the process
can crash. With it, it would lead to a memory leak due to the
ever growing queue of received events.

At the moment, we're relying on a Visual Studio solution when
building the extension. For this reason, simply doing a "pip install
PyMI" will fail as setup.py doesn't build the extension, expecting
it to be already built.

We're now letting distutils build our extension (keeping the VS
Solution as well for now). We're also switching to pbr, simplifying
version management.

The project structure will have to change a bit. Pbr seems to make
some assumptions about the project layout, so we'll have to move
setup.py in the top level dir, having wmi dir next to it.