Support scalar replacement of large structs

[daniel-story]

This PR fixes an issue where structs with over 100 member variables are not fully optimized by the default performance recipe. This is due to the default performance recipe initializing the scalar replacement pass using a default size limit of a maximum of 100 struct/array members as opposed to the infinite size limit explicitly requested by the size and legalization passes.

Failure to fully apply scalar replacement prevents effective optimization of shaders that access small portions of large structs. This leads to optimizable code related to accesses of such structs being left unmodified, resulting in large SPIR-V binaries and poor performance on some GPUs. Not applying these optimizations was found to have a substantial effect on performance in a number of production shaders from real-world game titles, so it makes sense to follow the lead of the legalization and size recipes and also remove this limit from the default performance recipe.

With this PR, the default value for the default performance pass recipe, the ScalarReplacementPass constructor, and CreateScalarReplacementPass are updated to zero to remove the current size limit of 100.

This PR includes a test based on a simplified version of the real-world production shader that uses a struct with ~180 members where this issue was first identified. This test aims to ensure that in the future running the default performance recipe on a similar shader will produce SPIR-V code that will not benefit from further scalar replacement with no limit.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[s-perron]

That limit was arbitrary, but it was put in because the compile time can get very long if sroa creates too many variables. If we remove it, there may be some follow up issues if the compile time increases for someone.

With that said, we could tell the users of spirv-opt to set their own limit based on their use cases. I think this should be fine. There is a workaround if there is a problem.

[s-perron]

You need to change line 116 as well.