Return future revision metadata with all record responses

[pospi]

RecordMeta.latest_revision should be returned in responses so that the latest live version of a record is easily located. In addition RecordMeta.future_revisions_count should be returned so that applications can easily display revision history summaries adjacent to record data.

This might have some implications regarding #196. There may also be shortcuts involved- for example, if get_* API endpoints are called (which accept an EntryHash as the record ID rather than a revision ID and always attempt to return the latest information available), then it is likely that the returned data can be interpreted as RecordMeta.latest_revision since it will automatically be the most recent information that the local Holochain node knows about.

[pospi]

see #40 (comment)

[pospi]

This also presents a solution space we need to flesh out regarding the handling of deleted records (see #145).

For the case of deleted records it seems sensible for RecordMeta.latestRevision to return the ActionHash of the deletion action. This could then be used to display a deletion tombstone and links back to previously present versions via RecordMeta.previousRevision for the deletion action's ActionHash.

There should also be some consideration given toward zome configuration attributes which determine whether this archival information is easily accessible by zome APIs. These would be merely enforceable as social contracts with mild technical augmentation- there's no guarantee that malicious actors within a network could not observe deleted data or that such data may be subpoenaed in the event of an investigation into a network.