typo fix

…discussed.

…lloc`).

(This really was an improvement, if only because it forced me to
realize that in some contexts in the text I was using the word "kind"
to mean something different than the layout structures being passed
around... which sometimes can seem like a nice pun, but overall I
suspect it was just a net increase in potential confusion.)

…o that contextual information can be fed back into the allocator itself.

Though on further review, the comment that inspired this,
  rust-lang#1398 (comment)
also wanted a `FormatArgs` argument too, so that the client code
could feed back in arbitrary info.

Added unresolved Q about the new `fn oom` method.

…`self`).

why `impl Allocator for &mut MyUniqAlloc` cannot just rely on
reborrows to handle satisfying `self` parameters.

…ess<'a>`.

…ves section.

Remove `fn dealloc_unchecked` method since it no longer provides any
benefit over `fn dealloc` anymore, since `fn dealloc` no longer has any
preconditions to check (*).

(*) Or at least, if it *does* choose to check preconditions (like "was
the address part of my set of memory blocks?"), there is no longer way
for `fn dealloc` to signal an error condition besides `panic`, and I
do not think trying to prepare for that hypothetical scenario is worth
adding the `fn dealloc_unchecked` method to the API.

…nsafe`)

(Though to be honest revisiting this made me wonder if I should just
require clients to implement `fn oom` themselves.)

…nger `Copy`.

(I should have done this as part of the earlier commit that removed
`deriving(Copy)` from `Layout`.)

…vacy oversights from earlier.

The demo code is still not perfect (it currently presumes
`Vec::new_in` addition, which is not great since another part of the
RFC now says that standard library integration is specifically not
addressed by this RFC). I'm working on revising the demo but I don't think
that should hold up overall discussion.

… trait itself.

(The only place where `AllocError` is used is as a bound on that
associated type, so does not present any additional burden on clients
of `Allocator` itself, though it does rule out certain pathological
programmtic constructions that I'm not worried about.)

…ocation failure cause.

The important one: for `Unsupported` operations, lets have the
allocator be able to provide more context about what was
unsupported. (I chose `&'static str` here because that avoids
allocation integration for the error message, but I would love to be
convinced that we could employ `Cow<'static, str>` here instead, since
that would be much more general purpose.)

And since I was adding contextual information anyway, I decided to
have the memory exhausted variant carry along the particular `Layout`
straw that broke the camel's back.

(Note that the `MemoryExhausted` *struct* still remains zero-sized.)

This includes the changes that were absolutely necessary to support
them in the `Allocator` trait itself, as well as an (opinionated) type
alias, `AllocatorObj`, for defining allocator trait objects.

 * Removed associated `Error` type from `Allocator` trait; all methods now use `AllocErr`
   for error type. Removed `AllocError` trait and `MemoryExhausted` error.

 * Removed `fn max_size` and `fn max_align` methods; we can put them back later if
   someone demonstrates a need for them.

 * Added `fn realloc_in_place`.

…ero`.

Revised specifications of (hopefully all) relevant methods to indicate
that they may or may not support allocation of zero-sized layouts (but
they should return an appropriate `Err` when given such).

(Now, the requirement to return an `Err` does imply a branch that
arguably we would like to avoid. It would be good to double-check
this, and potentially try to inline the initial checks into the call
site.)