[record_use] Completeness: Enable recording instances of subtypes

[dcharkes]

For record_use stable we need to know that this will not be a breaking change later.

Currently we prevent recording instances of types that are not final or have subtypes.

Theoretically we should be able to open it up. As long as the type hierarchy doesn't span package boundaries.

For now, this is low prio.

[dcharkes]

If we were to support extending, it would probably look like this:

• @RecordUse() annotation on the whole type hierarchy OR
  only on the shared base type
  • only on the shared base type would make it explicit where the instances will be reported in the format (next bullet point)
  • only on the shared base type would work better if we ever add configuration to @RecordUse(recordConstArguments: true). putting the annotation on the whole hierarchy would likely have to mean that the parameters should be identical in the whole hierarchy.
  • on the whole hierarchy would make the @mustBeConst annotations on all the constructor parameters make more sense because you also see @RecordUse on the class.
  • on the whole hierarchy would make the checking in the CFE easier, you can check the pragmas on the type instead of the pragmas on all the super types.
  • (either option is backwards compatible with the current approach)
• all instances would be reported on the shared base type OR
  all instance are reported on their own type AND we need to encode the type hierarchy in the JSON
  • If we were to allow for crossing package boundaries, then the results would be reported to the link hook in the package that defines the base type of the hierarchy. That package needs to define a contract with its users on what the shape of the subtypes is, but has no way of enforcing that via the compiler. (The safe option is to not allow it, and give an error when type hierarchies span package boundaries.)
  • (either option is backwards compatible with the current approach. The second option would simply be an empty subtyping relation.)

Supporting implementing quickly becomes hard to reason about:

• The const instances probably have completely different fields, so how would the author of an interface type of which all its implementations are recorded know how to use the recorded instances.