Obviate need for custom capability storage structs in inter-cell RPC calls

[pospi]

hREA-specific tracking of holochain-open-dev/dna-auth-resolver#2, which will likely resolve as being able to use built-in HDK methods to perform the capability storage and retrieval.

If it shakes out that way, we will no longer need to do a few awkward things:

• inheriting from the DNA Auth Resolver integrity zome along with type-specific integrity zomes will no longer be necessary, meaning we can use the standard #[hdk_entry_defs] macro with a simple struct rather than implementing the entry_defs and __num_entry_types externs manually.
• we will no longer need to genericise method parameters within the hdk_semantic_indexes library as per b4756be, since no custom storage for capabilities will need to be passed through the hdk_records RPC helpers.

[Connoropolous]

"meaning we can use the standard #[hdk_entry_defs] macro with a simple struct rather than implementing the entry_defs and __num_entry_types externs manually."

no, we still can't, because in some cases like economic_resource/storage we import resource_specification/storage, which would throw a conflict.

@freesig is working on a real fix, to do with rust-features or something