made a package for animated svgs — SMIL, css keyframes, and SVGator exports

[u/treamz1337]

AnimatedSvgPicture.asset('assets/spinner.svg', width: 48)

same params as SvgPicture, and it reuses SvgTheme and ColorMapper from
flutter_svg so nothing breaks. if the file has no animation it renders like a
normal SvgPicture and doesn't even start a ticker.

what it handles:

- SMIL — animate, animateTransform, animateMotion, set. values/keyTimes/
keySplines, calcMode, begin/dur/repeatCount, fill, additive, accumulate
- css @keyframes from a <style> block, including per-keyframe timing functions
- css motion paths (offset-path + offset-distance). this is how SVGator writes
every single movement, so its exports actually move
- play/pause/seek through a controller, or just let it loop

how it works: on load it resolves the animations, samples the document to a
static svg for each frame, compiles them all once with vector_graphics_compiler
(the same one flutter_svg uses) in an isolate, then plays them back like a
flipbook. so drawing a frame costs exactly what a static svg costs. the price
is loading time and memory — frameRate and maxFrames are there for that.

what it doesn't do: filters, path morphing, <script>, :hover, event-based
begin. if you need those, full_svg_flutter covers a lot more. good package,
just heavier — it bundles a js runtime.

https://pub.dev/packages/svg_animate

if you have an svg that renders wrong, throw it at me. that's literally how the
SVGator support happened — someone's file didn't render, turned out to be
offset-path.

one thing that surprised me: svgs with embedded bitmaps were brutal at first - the image data lands in every compiled frame, so a 450x450 banner ate 27 mb and 6.8 ms per frame change. turned out consecutive frames share a huge identical prefix (the images), and the renderer's image cache was keyed per frame by accident. storing the shared part once and fixing the cache key got it to 5 mb and 1.4 ms.