rfc 3/REMOTE-LOG: Improvements to remote log

These are things that can be improved in the current remote log design. No specific order. More details on each should be turned into its own issue, unless small enough to do a quick PR.

Spec

[ ] Elaborate on more specific requirements on CAS and NS
[ ] Tweak protobuf naming: response data return type a bit odd
[ ] Considering NameInit RPC for NS
[ ] Tweak protobuf naming: Better name than Pair?
[ ] More explicit sequence number https://github.com/vacp2p/research/issues/1 (Consider making more useful with metadata field, e.g. explicitly list what sequence a message is <local hash, remote hash, data, seqid> this way I can easily sync a messages prior or after a specific number)
[ ] Additionally, consider adding page info to remote log header to know which page a seqid can be found on
[ ] Document random joe node as CAS/NS remote log
[ ] Document how to find initial remote log (e.g. per sync context)
[ ] Document flow w.r.t each operation
[ ] Next page semantics: determine requirements re overlap/adjacent and/or missing entries
[ ] Elaborate on how to achieve 'deletion' of messages
[ ] Document message order requirements for remote log
[ ] Specify that NS is a global PKI namespace, implying authentication (for that specific keypair)

PoC / code

[ ] Extend spike to do full end to end flow as opposed to isolated CAS / remote log
[ ] Do end to end test with IPFS/IPNS, e.g.
- feasability study https://github.com/vacp2p/research/blob/master/remote_log/ipfs-feasability.md
[ ] Do some PoC that uses MVDS and/or status-console-client (possibly complex due to Nim/Go)