Add a FacetValue instruction

[josh11b]

The new FacetValue instruction represents C as I for some type C and facet type I. It is named FacetValue instead of just Facet to parallel the FacetType instruction.

This PR uses this instruction represent the facet value Self in an impl declaration. This instruction will be used in the future to also support things like:

• C as I where C is a class; and
• forming a specific for a generic with a T:! I parameter where T is being given a concrete value.

(Here I is an interface or other non-type facet type.)

Also do some renaming and add some comments to make things a bit more clear.

• FacetTypeAccess -> FacetAccessType to clarify this is not access of a facet type, but access of the type of a facet
• .facet_id -> .facet_value_inst_id to parallel the FacetValue instruction

FacetAccessWitness will be in a future PR.

[zygoloid]

Hm, I think this should be referring to the constant value of the FacetValue instruction, not to the instruction itself, or we won't properly deduplicate specifics for the same type.

Probably just need a constant_values().Get call when we create the FacetValue -- or you can pass the FacetValue directly to TryEvalInst to get a ConstantId without creating an extra instruction.

[josh11b]

The code is expecting an InstId, not a ConstantId -- is the idea that I will get the InstId for the constant? TryEvalInst also takes an InstId argument, should I pass in invalid or something?

[josh11b]

I updated the PR with the TryEvalInst approach with an invalid InstId. It does reduce the constant indices back, as well as changing the arguments to these specifics.

[zygoloid]

Should this be:

Suggested change

	push_inst_id(inst.type_inst_id);
	push_string(" as ");
	push_inst_id(sem_ir.types().GetInstId(inst.type_id));
	push_inst_id(sem_ir.types().GetInstId(inst.type_id));
	push_string(" as ");
	push_inst_id(inst.type_inst_id);

... because we process the pushed parts in reverse order?

[josh11b]

I applied this change, but it seems this isn't covered by any of our tests. When would this type be stringified?

[josh11b]

Added the test you suggested, which seemed to have worked! 1371f33

[josh11b]

Should I be concerned about the number of unused constants being generated? The most recent change seems to have increased how much this is happening: d605bf2