Rework how the client handles metadata errors

Errors at the partition-level of metadata should not, generally, affect the
update process itself. For the majority of such errors, Kafka provides what data
it can (i.e. when LeaderNotAvailable, it still gives the list of partitions,
isr, etc) and I can't think of a case where the stale data from the last
"complete" update is somehow more useful than the up-to-date partial data.
Especially when (for example) asking for the Leader, if ReplicaNotAvailable we
don't really care - we still have the leader id.

Based on this logic:
- Partition-level errors during a metadata update are no longer returned from
  the update call itself. The update is considered to succeed as long as all
  topics were successfully handled (mid-election partitions are still retried
  after a brief delay).
- Partition-level errors are instead returned from actual requests for the
  relevant data (e.g. if a partition got LeaderNotAvailable, that is still
  returned from a call to Leader(), but only for that partition, and a call to
  Replicas() would still return the actual replicas with no error).

Side change: get rid of NoSuchTopic, kafka already has UnknownTopicOrPartition
Implement Client.WritablePartitions

It returns the list of partition IDs (like normal Client.Partitions) except
limited to those partitions which have leaders that are available and accepting
writes.

Bonus fixes:
- permit setting the error field in MetadataResponse.AddTopicPartition
- add "closed" check to Replicas and ReplicasInSync
- permit MetadataRetries == 0, which is at least logically coherent (and
  behaves sanely), even if it's not usually useful
Rework Partition interface and usage

- permit Partition() to return an error, since the HashPartitioner can
  theoretically hit errors calculating the hash or materializing the key
- have each partitioner indicate whether it requires consistency or not

A partitioner that requires consistency (primarily the HashPartitioner) is one
for whom "partition not available" means "fail the message" as opposed to "try
some other partition" (which is better behaviour for the RandomPartitioner, for
example). Respect this value in the producer by using Partitions() or
WritablePartitions() depending.
tweaks to address code review comments
Merge pull request #215 from Shopify/consistent-partitioning

Consistent partitioning
Preparatory steps for the new consumer

Some miscellanious changes I found necessary while developing it, that have been
separated out so they can land first:
- define `type none struct{}` for convenience
- implement `FetchResponse.AddError()`
- prefer the seedBroker when fetching metadata, it makes client behaviour much
  more deterministic and easier to test in multi-broker setups
Merge pull request #220 from Shopify/consumer-ng-prep

Preparatory steps for the new consumer
Fix the rebase I screwed up
Rewrite consumer to support multiple partitions

- `Consumer` is now a much lighter "manager" that spawns `PartitionConsumer`s
  instead. `PartitionConsumer`s behave and have an API almost exactly like the
  old `Consumer`.
- Automatically groups and redispatches PartitionConsumers when leadership moves
  in the cluster.