*: Split etcd into 3 modules:

      go.etcd.io/etcd/v3 - server
      go.etcd.io/etcd/c/v3 - client code
      go.etcd.io/etcd/integration/v3 - integration tests

This was discussed an community meeting on 2020/07/30. The goal is to
minimize number of dependencies that our network customers needs to
carry and clearly define packets that needs to stay backward compatible.

Main files moves into ./c
  Clients:
    ./{client,clientv3}
  API protos:
    ./etcdserver/api/membership/membershippb
    ./etcdserver/api/v3rpc/rpctypes
    ./auth/authpb
    ./mvcc/mvccpb
    ./etcdserver/etcdserverpb
  Integration tests:
    ./client{v3}/{integration,concurrency} -> ./integration/client{v3}/{integration,concurrency}

Tested using:
  PASSES="unit integration functional e2e" time ./test -v

  ./build

  (go build ./... && go test ./...)
  (cd c; go build ./... && go test ./...)
  (cd integration; go build ./... && go test ./...)

  ./scripts/genproto.sh

  make

  go mod tidy
  go mod vendor

Futher steps:
 - migrate etcdctl into (c) - client code. This requires spliting some
  admin functionalities that operate directly on etcd server files.

Documentation/dev-guide/api_concurrency_reference_v3.md

@@ -143,7 +143,7 @@ The election service exposes client-side election facilities as a gRPC interface
 
 
 
-##### message `Event` (mvcc/mvccpb/kv.proto)
+##### message `Event` (c/mvcc/mvccpb/kv.proto)
 
 | Field | Description | Type |
 | ----- | ----------- | ---- |
@@ -153,7 +153,7 @@ The election service exposes client-side election facilities as a gRPC interface
 
 
 
-##### message `KeyValue` (mvcc/mvccpb/kv.proto)
+##### message `KeyValue` (c/mvcc/mvccpb/kv.proto)
 
 | Field | Description | Type |
 | ----- | ----------- | ---- |