is `SUnitRange` static?

[ExpandingMan]

I was about to write a PR to make static(n:m) work, but I realized I may not fully understand what's going on here. I had believed that static(n):static(m) which has the SUnitRange alias of OptionallyStaticUnitRange type would be considered static, however the interface indicates that it is not (both via is_static and known) so I now believe this was all deliberate.

I suppose whether SUnitRange is "static" depends on how the compiler treats it. I suspect that using it does not guarantee loop unrolling or anything like in and of itself, bu that but this can be hard to check since the compiler will unroll or elide small loops on its own a lot anyway.

My suggestion is: if SUnitRange should be considered static, static(m:n) should return it and known and is_static should work. Otherwise, if it is not, there should be some clarification in the docs about what exactly these are and what they are used for.

[Tokazama]

This may lead us down a more complicated path than anticipated. Wouldn't that mean that any collection that could be remade in static terms would overload static. For example, would this mean that static(x::LinearIndices) = LinearIndices(map(static, axes(x)))?

I'm not necessarily against this, but if we do expand what static does we should figure out how to manage the potentially increased demand to support static for new types moving forward in a consistent way.