Collections Reform Part 2

This RFC shores up the finer details of collections reform. In particular, where the previous RFC
focused on general conventions and patterns, this RFC focuses on specific APIs. It also patches
up any errors that were found during implementation of part 1. Some of these changes
have already been implemented, and simply need to be ratified.

[rendered](https://github.com/Gankro/rfcs/blob/collections2/text/0000-collections-reform-part-2.md)
`Vec` is a bit of an outlier because we know precisely which type we're implementing `Deref` for, which is just a slice. `Rc`, on the other hand, is a good point! Looking back at its API there are more methods than I originally thought.

However, in general it's a pretty dangerous operation to implement `Deref` because it means we'll never be able to backwards-compatible add a method to an `OccupiedEntry` (or `Rc` for that matter). In the case of `Vec` we can continue to add methods because we know exactly what we're deref'ing to, and we can know if they clash or not. 

We don't currently have strong conventions around when to or not implement `Deref`, so I guess I should rephrase my concern/question: How sure are you that the API of `OccupiedEntry` will not need to grow in the future?