Currently we do not allow inlining any methods that have unmatched
type parameters. The original reason for this restriction is that
I didn't really know what to put for an inlined :static_parameter,
so I just had inlining bail. As a result, in code like:

```
f(x) = Val{x}()
```

the call to `Val{x}()` would not be inlined unless `x` was known
through constant propagation.

This PR attempts to remidy that. A new builtin is added that computes
the static parameters for a given method/argument list. Additionally,
sroa gains the ability to simplify and fold this builtin. As a result,
inlining can insert an expression that computes the correct values
for the inlinees static parameters.

The change benchmarks favorably:

Before:
```
julia> function foo()
          for i = 1:10000
              Base.donotdelete(Val{i}())
          end
       end
foo (generic function with 1 method)

julia> @time foo()
  0.375567 seconds (4.24 M allocations: 274.440 MiB, 14.67% gc time, 72.96% compilation time)

julia> @time foo()
  0.012387 seconds (9.49 k allocations: 148.266 KiB)
```

After:
```
julia> function foo()
          for i = 1:10000
              Base.donotdelete(Val{i}())
          end
       end
foo (generic function with 1 method)

julia> @time foo()
  0.003058 seconds (29.47 k allocations: 1.546 MiB)

julia> @time foo()
  0.001200 seconds (9.49 k allocations: 148.266 KiB)
```

Note that this particular benchmark could also be fixed by #44654,
but this change is more general.

There is a potential downside, which is that we remove a specialization
barrier here. We already do that in the case when all type parameters
are matched, so it's not eggregious. However, there is anectodal
knowledge in the community that extra type parameters force specialization.
Some of that is due to the handling of type parameters in the specialization
code, but some of it might also be due to inlining's prior refusal
to perform this inlining. We'll have to keep an eye out for any
regressions.