Websocket Loading Manager

[german-e-mas]

This PR solves the issue of keeping track of assets loaded via the websocket server. This is required for clients to have a "loading" behavior available.

---

Context

Loaders are in charge of loading, parsing and using any kind of resource. They have a loading manager, which is usually a default one unless provided.

The Loading Managers are in charge of handling and keeping track of loaded and pending data. Whenever a resource begins to being fetched, it increases the number of total items handled. When an item ends, the number of loaded items increases. Then, when the number of loaded items equals the total, the loading manager considers it has finished.

Here's the current workflow that happens whenever we call a Loader's load method. The diagram is only meant to be a guide.

When a loader's load method fails, we use its onError callback to handle the asset via the websocket server. At this point, the loader manager already marked the item as error, and called it's end.

---

Solution

We now use a custom Loading Manager to avoid marking items as done whenever their loader fails.

If we use the websocket connection to get assets, we need to provide a new WsLoadingManager to loaders.

The WsLoadingManager extends a Loading Manager and allows it to keep track of the items the loaders tried to load and failed to do so. This way, when itemError is called, we keep track of the item, and when itemEnd is called, we know it had an error, so we don't mark it as done (yet).

When we get the asset from the websocket callback, we can manually mark it as done. Or, mark it as error, if we failed to get it.

---

This is a very non-intrusive way to handle assets via websocket connections. This way we don't have to modify loaders directly, which is something that is very hard to keep track of.

Note: Our ColladaLoader still uses the websocket callback inside of it and had to be modified, but I'm quite sure it can be avoided. We can modify it in the future if needed.

---

Another potential way to solve this issue is to have a Loader class that encompasses regular loaders with the websocket fallback, but it has been quite challenging to do. This is the easiest way I found to bring a solution to this problem.

---

Can you ptal @nkoenig ?

[german-e-mas]

@nkoenig , I'll be merging this in order to unblock other projects. We can iterate over this implementation again in the future, if needed.