Restore ability to use same link type for multiple base types

[pospi]

Since updating from 0.0.18 to 0.0.27 I am getting errors like this one:

Wrong base type for link of type 'record_initial_entry'. Found 'vf_commitment_base', but link is defined to link from 'vf_intent_base's.

It would be nice to restore an ability to mix and match more arbitrarily, as losing this effectively prevents polymorphism and clean abstractions for record data structures. I now have to:

• create additional constants for link types which have the same meaning, impeding sensemaking capabilities of generic zome explorer interfaces in the process (commitment_initial_entry and intent_initial_entry instead of record_initial_entry)
• complicate my generic create_record helper such that every create_record call needs to provide an underlying link name; or simply remove the link entirely, which was only present for semantic hinting in external tooling like zome explorer interfaces anyway.

Neither of these feel like great outcomes- losing some flexibility and potentially causing developers to shy away from creating easily explorable data structures. Or is "Address as content" a reasonable design pattern which implies an ability to crawl from one data object to another?

[willemolding]

I want to bring @zippy in on this discussion. What are some of the reasons for strictly enforcing base and target types for a given entry type?

The first thing that springs to mind is that without this there are extra responsibilities for the DNA developer to make sure that links can't be added to break certain data structures or load up certain bases with links.

I wonder if we could lessen the validation done by the subconscious and make the link creation macros able to do this in WASM but only if required?

[pospi]

I guess I see what you're saying, but still feel like this is overly restrictive. If people accidentally use the same link_type in multiple entry defs, shouldn't that be pretty easy for them to debug? Those link type names are emitted by the console on both read & write ops.

[pospi]

See commit referenced above to get a sense of the additional verbosity and plumbing needed to deal with this change.