Remove parameter-constant arrays from import_ref

[geoffromer]

This makes the code more resilient to changes in the structure of parameter insts, and could help avoid bugs by making the ImportRefResolver's data structures the single source of truth.

[zygoloid]

This is a deviation from the approach used in the importer, which is otherwise divided into a gathering-constants phase followed by a building-things-using-the-gathered-constants phase. To me, it seems like this approach is a little less robust: with the prior approach, GetLocalParamRefsId gets the known-to-already-be-loaded things from its arguments, so it's harder to have forgotten to load them in advance, whereas in the new approach, if there's a load call missing in LoadLocalParamConstanatIds, there's nothing to detect that statically. If we applied this globally throughout this file, I would be worried that it'd be quite easy to have the set of loading steps not match the set of things used while building.

However... the new approach would make it easier to import more complex data structures, which seems like a substantial advantage. I wonder if there's some larger refactoring we can do here to get that advantage with the same or a higher level of robustness. For example, some way to use the same code to fetch the constants that we use to build the new values, so that they can't diverge.

I'm approving to unblock the work to add support for importing patterns in function parameters, but given the divergence in approach between this and the rest of the import logic, I think we should have a more holistic look for another approach here.

[geoffromer]

Would you like me to add a TODO to find that more holistic approach?

[zygoloid]

Would you like me to add a TODO to find that more holistic approach?

Yeah, I think that'd be good, and to call out that we're doing something unconventional here.

[geoffromer]

OK, done.