This seems like a poorer developer experience-it's out of keeping with other similar `flutter/flutter` widgets (see LinearGradient.stops([URL]) and requires a ton more boiler plate. Readability and editability for `SnapSizes()..add(.1)..add(2)` is pretty poor.

Also, what does it mean for `snapToMin/Max` to be false? That the sheet slides without snapping between the outer snap points and the min/max? That sounds like very strange UX that we'd not want to expose...Or the sheet could always snap to the available snap points so you could drag to the max size, but if max size isn't a snap size, you'd snap back down to the nearest snap size. That sounds more sane, but still weird UX.

And this construction still doesn't ensure that users don't attempt to specify snap points that are outside of min and max-we'll still need an assert at least for that case.

What do you think about staying with just a plain old list and a bool (or just a plain list and no bool, with the added caveat that this means an empty list will enable snapping which is awkward...)? This keeps us in line with the one comparable example I know of (`LinearGradient.stops`) and it feels like we're adding a lot of complexity to avoid relying on assertion errors, I'm not sure I see the tradeoff being worth it.

I could move the assertion errors into the sheet's constructors so it's easier for devs to interpret the stacktrace-would that help? and/or we could return an ordered list instead of throwing if an unordered list is provided-but I think it's better to loudly fail than silently do something weird-I can't imagine a developer intentionally supplying an undordered list-it'll make their code way less readable. If the list is unordered, it's probably the result of a bug and it's better to fail so the developer can root cause the issue than to continue with potentially unintended `snapSizes`.