Cap calls to with_capacity with sane default

[TyOverby]

For instances where the length of a collection must be obeyed, but is
untrusted, calls to with_capacity() could result in OOM errors.

This change makes it so that collections don't pre-allocate more than
1MB of memory.

[TyOverby]

This should be close to the final implementation, however I still need to write a test that would crash current HEAD, but passes with this change.

[alexcrichton]

Looks good to me, thanks! I'm fine merging with or without a test

[TyOverby]

I have a few more questions:

What happens inside of Vec and HashMap when they contain zero-sized types? My implementation lets them allocate all they want under the assumption that there isn't really any allocation being done. Is this a reasonable assumption?

Do you want me to include the version number bump?

[alexcrichton]

For Vec at least I believe no allocations are made, for HashMap though I'm not sure (cc @pczarn, @cgaebel, @gereeter, sorry, I forget who's most familiar with HashMap internals!). I think, however, it's a reasonable assumption.

I'll include a separate version bump after this, so no need to include it here

[gereeter]

Vec definitely does not allocate when fed zero-sized types, but HashMap and BTreeMap currently do. However, there isn't any particular reason why they have to allocate - the code optimizing for ZSTs just hasn't been written.

[TyOverby]

@alexcrichton I've updated the PR to cap with_capacity for zero-sized-types.

[alexcrichton]

Thanks! Did you want to add some tests as well?

[TyOverby]

@alexcrichton I haven't yet, but I will tonight.

[TyOverby]

@alexcrichton The code has been updated with a test.

[alexcrichton]

Thanks @TyOverby!

[TyOverby]

@alexcrichton Could you bump the version number and publish to crates.io? I'd like to include a regression test in bincode for this scenario.

[alexcrichton]

Huh I thought I did that... sure though!