Blender Git Loki

Add experimental 'asyncio-based' version of Amber.

This was done to both test asyncio usage in an 'asset engine' context, and wet my feet with this lib.

All in all, am really not convinced by asyncio in this use-case. async and coroutines are much more
complex to grasp and get working correctly (and efficiently!) than mere threading.
Further more, most python lib callbacks (os.listdir, os.ls_stat, etc.) are not async-ready,
so you have to call them through asyncio's executor (aka threads or processes),
which means using asyncio in this context is only adding overhead.

I think asyncio is only really relevant when you have to handle tens (and much more) concurrent I/O tasks,
otherwise threading (or multi-processing if compute-intensive) are much, much simpler to get working,
and also probably lighter in terms of overload?

Further more, asyncio paradigm is not so easy to adapt to the 'AssetEngine' paradigm, i.e. a
python interface that gets called to start, query and finalize jobs that are supposed to keep running
in-between (think event loop should run in a background thread actually...).