Refactor a List.generate to List.filled

[natebosch]

The meaning is more clear without the indirection of a closure that
always returns the same value, and it will have better performance.

Also replace the List.insert by making the length longer to start
with and conditionally setting the first value.

[natebosch]

I was originally going to write this with a List.filled since the closure that always returns the same value is unnecessary and likely inefficient. Upon a closer look I think the list literal version is more clear than needing a list.insert(0 call to put a new element at the beginning of the list. In the list literal form the order and size of the list are both more clear in my opinion.

[kevmoo]

Nice! Worth an entry in the changelog?

...seems like this might could improve perf

[jakemac53]

...seems like this might could improve perf

Probably not, its possible but last I checked (recently) collection-for is still slower 🤷

[natebosch]

collection-for is still slower

I could do

    separators = List.filled(newParts.length + 1, style.separator);
    if (!isAbsolute || newParts.isEmpty || !style.needsSeparator(root)) {
      separators[0] = '';
    }

WDYT?

[natebosch]

To be clear, my primary goal is readability and I don't plan on spending time trying to microbenchmark this.

Now that I wrote out this new List.filled version I think I might even be leaning towards it as my preference for most readable...

[jakemac53]

I am fine with either version, I wouldn't focus on micro-benchmarking this. I just wanted to refute the idea that collection for is fast, cause it isn't today :D.

[natebosch]

Worth an entry in the changelog?

No longer changing the min SDK so shouldn't be anything user visible. Likely does improve perf but I'm not going to bother benchmarking and I don't think it's worth calling out specifically in the changelog.