Incremental loader

[Shinmera]

This PR changes the loader system to be incremental rather than staged as before. The staged loader has the following potential advantages:

• Loads can be smoothly aborted and rolled back
• Unneeded things can potentially be unloaded before new loads, avoiding memory pressure issues
• It is conceptually cleaner

However, experience has shown that there are several common situations where it is impossible to construct a full staging area ahead of time, as resources and dependencies only become clear during the loading process itself.

This new system instead loads things incrementally and instantly. For backwards compatibility it uses a very similar interface to before; a stage function to mark things for loading. Unlike before, staged objects are now immediately loaded and dependencies fulfilled instantly, rather than registering and sorting.

Along with this we have a new observation mechanism, which allows objects to be notified when a resource or asset changes its state during the load operation. This allows objects to react to loading and, critically, stage additional objects once they become available.

This supersedes the previous generation observer mechanism, and removes another global registry, as load observations are always local to the load operation in progress, rather than local to a globally registered asset. Thus this is not entirely backwards compatible, users need to remove uses of generation observers and instead switch to using load observers.

The same load observation mechanism is also used to let shader passes react to new entity types being staged that they did not previously record shader programs for. This removes the second problem, where if an object changed the scene graph during load, shader passes would not have constructed or loaded the required programs.

This PR will remain in draft status until the feature is complete and documentation has been adjusted.

[3b]

i think this might work more correctly?

(defmethod find-frame-idx ((track fast-animation-track) time loop-p)
  (declare (optimize speed))
  (let* ((frames (frames track))
         (size (length frames))
         (time1 time))
    (declare (simple-array frames))
    (if (< 1 size)
        (let* ((rate (sample-rate track))
               (time (fit-to-track track time loop-p))
               (duration (duration track))
               (samples (truncate (+ rate (* duration rate))))
               (time (/ time duration))
               (index (truncate (* time (1- samples))))
               (sampled (sampled-frames track)))
          (declare (type single-float rate time duration))
          (declare (type (simple-array (unsigned-byte 32) (*)) sampled))
          (declare (type (unsigned-byte 32) index samples))
          (if (< index (length sampled))
              (loop with l = (1- (length frames))
                    for r from (aref sampled index)
                    while (and (< r l)
                               (< (animation-frame-time (svref frames (1+ r)))
                                  time1))
                    do (incf index)
                    finally (return r))
              -1))
        -1)))

(+ rate (* duration rate)) part still seems odd though (if not in a way that breaks things). If, for example, the duration is 0.25 you end up with 5x sampling rate for that quarter second, but as duration increases the actual sampling rate asymptotically approaches the requested sample-rate.

[Shinmera]

Okey, this PR has grown a bit beyond what it was meant to contain and also includes a bunch of fixes for the animation system, since I'm a messy bitch.