Clarify bitswap, graphsync, blocksync usage

Filecoin nodes send & receive block data from each other at 3 different stages:

Chain sync - the initial sync of all blocks in the chain, from genesis until now (data size: moderate, ~mb-gb)
Chain updates - ongoing updates of new blocks as they are added to the chain (data size: small, ~kb)
Data transfer - the sending & receiving of client data, per storage and retrieval markets (data size: large, gb+)

Currently the spec & implementations each use different permutations of 3 protocols for these stages.

After verbal discussions with @jbenet @anorth @whyrusleeping @ZenGround0 @hannahhoward we agreed on this:

1-2. Chain sync & chain updates: Nodes MUST provide chain data over graphsync.
- Nodes MAY also provide chain data via blocksync and chain updates via bitswap.
- Note: lotus plans to support both.
3. Data transfer: Nodes MUST get and send data over graphsync for storage and retrieval deals.
- We chose graphsync because data transfer is a point-to-point use case that requires verification. Using bitswap to transfer a lot of data requires making lots of sequential requests to cover the tree, requiring lots of round-trips. Graphsync is based off a block + selector, so is more efficient, and it also supports verification.
- Note: go-filecoin and lotus plan to add bitswap support for more direct compatibility with today's IPFS, but this is not required for a complete Filecoin protocol implementation.

[ ] Update 2.6.3.6 Chain Sync section with clarifications to syncing protocols
[ ] Stub out bitswap section (3.5.1) with link & summary.
- [ ] Also move to appendix.
[ ] Stub out graphsync section (3.5.2) with link & summary
[ ] Move blocksync section to appendix and mark as optional.

Related: #782, #461, #442

filecoin-project / specs