Refactor sampling module with new functional submodule

[Beinsezii]

• Functional sampling structures
• Move all of the non-functional samplers
• Runge-Kutta sampler
  • Better substep interpolation than 1d linear?
  • Unified derivative
• Adaptive sampling?
  • Heun-Euler might be easy.
    • Just kind of yolo'd the evaluation. Might have to check what other impls do.
  • Should refactor tableau processing now that they're used twice.
• Self-accurate unit tests
  • Diffusers unit tests? FlowMatchHeunScheduler might work at least.
• Plots
• Examples
• Investigate running in Diffusers
  • Possibly could replace the LoopSequentialPipelineBlocks portions of ModularPipeline with a generic wrapper since they're small
    • A demo was created at examples/diffusers/functional.py using Flux. The API is very rough so I will probably hold off on making this an official interface until diffusers figures out their modular system more. Maybe I should open an issue suggesting a more functional-compatible system?
    • I opened a discussion upstream Functional Sampling for Modular Diffusers huggingface/diffusers#12405 to see if this is even the right path.
  • For samplers with a pre-determined step size ie Runge-Kutta I guess I could try the native diffusers higher order code by having SkrampleWrapperScheduler present some kind of generator over its own step function as model(x, t)?
    • This assumes they handle timesteps as an arbitrary sequence and don't assume it's whole steps which would only work for Heun. It would also involve pre-building the whole schedule splattered across the tableau, including skips for T=0.
    • It would also need to have another callback for all intermediate steps which is crazy unfortunate. I would honestly rather intercept the Euler calls and just copy the intermediate terms out of them.

[Beinsezii]

Think I've added pretty much everything I could need for a first implementation. RKMoire and FastHeun are both crazy jank still but not sure what to do about that since diffusion is really chaotic.

[Beinsezii]

Basically, a lot of areas need follow-ups but most of it is no longer problems with the functional module but rather other areas of the library that need improved robustness as a result of findings in this PR:

• ModelTransform invasion
  • Should be sent through to StructuredSampler and anywhere else that currently expects an X prediction
  • Will get super hairy with UniPC and DPM to avoid double-converts
• Paramtetrize all tests Parametrize Tests #58
  • Much easier to debug large refactors. Should start with this
  • Possibly also works better with the parallel extension.
• Possibly make schedules continuous over T
  • Mostly depends if Scaled can be made a continuous function.
    • Would probably need to hugely boost the test epsilons because I'd need to remove the round()
  • Would allow sending SkrampleScheduler directly instead of FloatSchedule, basically eliminating the sigma_transform variable. Would no longer be any point in assigning schedule into FunctionalSampler.
• Possibly make RNG continuous over T
  • Might be better to do this in numpy/scipy?
  • Or I could actually make BrownianInterval the base class that Pyramid/Offset inherit from.
• Possibly add RKUltraWrapper
  • By taking tableaux without overlapping timesteps like RK3.Ralston, it could be done purely with exact T indexing as we currently do.
• Possibly add ComfyUI nodes
  • Requested
• Add more obscure tableaux as I find them
  • Saw references to Feagin embedded 14/12 in some papers which sounds baller as hell but I really need a nice premade tableaux to have any hope of making it correct.
• Improve RKMoire usability
  • Saw some junk in papers that could help but I'll need QwenVL to explain it to me as a child tbh.
• Add DPM++ Singlestep methods
  • Mostly interesting because it implements stochastic sampling. Otherwise I'm not sure it's better than RKUltra.
• Add whatever this is Res samplers? #52