* master: (25 commits)
  go/neo/neonet: Teach Dial to autodetect server encoding
  go/neo/neonet: MessagePack support for link layer (draft)
  go/neo/proto: Cosmetics
  go/neo/proto: MessagePack support for messages (draft)
  go/neo/internal/msgpack: New package with runtime support for MessagePack
  go/neo/proto: protogen: Prepare to generate code for struct heads
  go/neo/proto: protogen: Factor-out handling of slice and map heads into common place
  go/neo/proto: protogen: Fix naming thinko in decoderN.genBuf
  go/neo/proto: Introduce Encoding
  go/neo/proto: Unexport Msg.NEOMsg{Encode,Decode}
  go/neo/proto: Kill outdated TODO
  go/neo/proto: Unexport Msg.NEOMsgCode
  go/neo/proto: protogen: Reuse sizer for typeSizeFixed
  go/neo/proto: protogen: Load zodb.Tid and zodb.Oid types
  go/neo/proto: protogen: Factor-out code to lookup object for <pkg>.<name> into common function
  go/neo/proto: protogen: Clarify criteria to detect []byte
  go/neo/proto: protogen: Fix it not to silently skip a pointer field
  go/neo/proto: AddrString: Also treat lonet networks as having addr in host:port form
  go/neo/neonet: Adjust pktAlloc to always allocate pktBuf with cap >= PktHeaderSize
  go/neo/neonet: Factor-out decode of packet header into pktHeadDecode
  ...

NEO/go server accepts preferred encoding of client from start, but
NEO/py server implements either N or M encoding and disconnects client
silently if handshake is not exactly what is expected.

However we can teach Dial to retry with different preferred options and
this way when connection to a NEO/py server, it will essentially
autodetect which encoding is used and accepted by remote peer.

This patch adds support for serializing packet frames with M encoding on
the wire. To do so it follows rules defined in

    	nexedi/neoppod@9d0bf97a
    	( nexedi/neoppod!11 )

Server handshake is reworked to autodetect client's preferred encoding.
Client always prefers 'N' for now.

This patch adds proto.Encoding('M') and teaches it to encode/decode
messages via MessagePack by the rules defined in

	nexedi/neoppod@9d0bf97a
	( nexedi/neoppod!11 )

It only adds support for messages serialization, without changing
proto.go to match changes in e.g. enums reordering, and without adding
support for MessagePack at link layer in neonet.

M-encoding was only tested for NEO/go-NEO/go, and was not yet tested for
NEO/go-NEO/py interoperation. There will be likely small mistakes
discovered on my side that should be hopefully easy to fix step by step
once we get to that phase.

It complements github.com/tinylib/msgp with things that neo/proto needs
to encode/decode messages.

It is noop for 'N' encoding, but will be non-empty for MessagePack.

genSliceHead and genMapHead will be reused for MsgPack encoding.
Changes in generated code are mostly due to move of where things are
typecasted to e.g. uint32 without any change in semantic.

For decode-family of functions protogen.go sticks to convention to name
target variable to where to assign the result as "assignto", not "path".

No change in generated code.

Encoding specifies a way to encode/decode NEO messages and packets.
Current way of how messages were encoded is called to be 'N' encoding.

This patch:

- adds proto.Encoding type
- changes MsgEncode and MsgDecode to be methods of Encoding
- renames thigs that are specific to 'N' encoding to have 'N' suffix
- changes tests to run a testcase agains vector of provided encodings.
  That vector is currently only ['N'].

And provide only single top-level entry-points to encode/decode
messages. As of now the entry points are just plain forwarding, but with
introducing of msgpack and encodings, they will take into account
through which encoding a message has to be encoded/decoded.

- Regrouping messages would change their message codes, thus introducing
  backward compatibility breakage.

- The protocol itself is currently kind-of documented in separate
  document here:

  https://neo.nexedi.com/P-NEO-Protocol.Specification.2019?portal_skin=CI_slideshow

It is internal detail that ideally should not get outside of proto
package. Don't clutter documentation of all messages with it.

-> For now access message code via proto.MsgCode(msg) from outside.

Generating code through sizer can already give answer if a type is fixed
size or not. And in practice we don't care at all if it will be a bit
slower compared to previous explicit type switch.

For current code it is just a small cleanup, and it will be handy to
support messagepack encoding as well.

No change in generated code.