Fix out of memory errors / improve resourcecollector

[Christian Thäter]

Initially I planned that lumiera_malloc never returns an error, it invokes the resource-collector to free some memory and if that is impossible we do an emergency shutdown (registered in the resourcecollector, if nothing is registered there, then the resourcecollecor will abort()).

This plan has some fundamental (but fixable) flaws:

We can't invoke the resource-collection cycles from the calling thread because it might hold an undefined number of locks, thus this thread run the shutdown, it can barely signal the emergency shutdown, which is ok, but then it has to return. This means that functions calling the resource collector are not guaranteed to never return an error but there might be an error passed back.

New plan:

With thinking about profiler and resource buckets the resource-management system should be proactive, either running in the main thread or in its own thread. Details will be worked out. (i write RFC's for that soon). Basically we establish some condition variables which will be used to pass states between resource requesting jobs and the resourcecollector around.

[Ichthyostega]

While we retain the underlying idea that resources are managed proactively, overall the Architecture of Lumiera has shifted dramatically: the idea of a common »back-end« that sits like an OS below any other application core, has been abandoned.

This shift has been foreshadowed for a long time, and this is likely the reason why the idea of the profiler and resource-collector was not developed further. We will retain the idea, not the implementation approach.

See for context:

• my "caveat" comment in the RfC ResourceManagementProfiling
• my rationale for dropping the RfC DataBackend
• and the the related #683