Faster to_strict_string, accepts, and slightly faster to_functional_string

[dfellis]

I followed the pattern in to_functional_string with to_strict_string, and the initial version was actually slower on average than the original that constructs a ton of temporary strings.

I was puzzled by this, but then realized that Rust was not able to turn the CType::Infer values I was creating at the beginning of the loop into constants, and was actually constructing those strings on each call. Because the number of these quasi-constant strings needed for to_strict_string was much higher, this pushed the average number of string allocations up instead of down.

So I used OnceLock to lazily create a singleton for each of these quasi-constants and that gave me the speedup, and I re-used this in to_functional_string to make that slightly faster, as well.

While rewriting to_strict_string I realized that the accepts method, which was the actual largest bottleneck (via using to_strict_string mostly), didn't need to call the degroup method because the string output would be identical either way, so I dropped that and got a further performance boost. Now the Hello, World example program takes just 2 seconds to compile on my laptop, and running it in Firefox is now faster than what the native compiler was a couple of days ago at just under 3 seconds (while Chrome is sitting at about 5.5 seconds).

[github-advanced-security]

clippy found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.