Rename `IpfsDHT` to `Kad` or something else

[hsanjuan]

While IPFS uses this DHT, this DHT does not need IPFS for anything.

[KristenPire]

I think the same as you, and so i've made a PR for this issue.

[gpestana]

I remember the naming has been kept for backwards compatibility, so you probably want to keep an alias too (cross comment to the PR #338). @anacrolix opened a PR to solve this not too long ago, but the merge got postponed. The discussion shows why (#223)

[aschmahmann]

I disagree with this idea given the current way this library is set up. However, if we were prepared to make a couple changes I'd be all for it.

1. The protocol ID is here and listed as /ipfs/kad/1.0.0
2. There is special handling for the IPFS use case of Provider records instead of just Get/Put.
   • Provider records could just be special handlers on Get/Put that deal with Key-MultiValue instead of Key-Value
   • Key-MultiValue could have separate Get/Put that are not restricted to provider records

[anacrolix]

A cleaner DHT interface can be ripped out from IpfsDHT, and IpfsDHT made to wrap it, conforming the expectations asserted at

go-libp2p-kad-dht/dht.go

Lines 73 to 81 in a12e621

	// Assert that IPFS assumptions about interfaces aren't broken. These aren't a
	// guarantee, but we can use them to aid refactoring.
	var (
	_ routing.ContentRouting = (*IpfsDHT)(nil)
	_ routing.Routing = (*IpfsDHT)(nil)
	_ routing.PeerRouting = (*IpfsDHT)(nil)
	_ routing.PubKeyFetcher = (*IpfsDHT)(nil)
	_ routing.ValueStore = (*IpfsDHT)(nil)
	)

.