Create macros to minimise boilerplate when defining new records & zomes

[pospi]

Once #18, #19, #20 & #21 are completed we will have covered most of the data structures needed for VF records. This would be a good time to take the thus-far unavoidable field duplication and verbose impl definitions in the core VF modules and turn those into macros so that the code is kept as DRY as possible.

[sqykly]

Rather than working this into the spec branch, this probably wants its own branch. Agreed?

[pospi]

Yes of course. Ideally every issue should have its own branch.

[pospi]

For clarity: this is about reducing the boilerplate within each VF record definition file by taking out the repetition currently needed in defining entry / create request / update request / response structs and the logic inbetween them. It does not cover pulling common field definitions out to reduce the boilerplate needed in eg. defining note for each separate VF record.

A good way to approach this is probably to come to agreement on what the final record definition should look like, and then work backwards from there to implement the macro which will translate that into something similar to the current verbose record definition code.

[pospi]

Something else to note: we are likely moving to a pattern where referenced fields have separate methods for manipulating them, rather than being editable as fields of the main record structures.

As such, it's likely that the only wiring of link fields into a record is in the READ phase. It's also likely that we will want other types of non-editable "derived" fields in addition to link-based ones (eg deleteable).

All this being the case, my suggestion would be to implement derived fields as callbacks which accept the input Address and return whatever field data is needed. This would basically replace all zome-layer calls to construct_response with a call to some new record-layer method that knows how to read the links internally. But let's be sure we are happy with the revised update logic before doing that since it impacts the ability to construct a response from the input links in a CREATE request...

[pospi]

Looking good after implementing hdk_records and hdk_semantic_indexes- pretty much all zome-specific logic is now specific to that datatype and avoids repetition of basic CRUD and indexing logic.