Add inout crate and prepare block-padding v0.3

[newpavlov]

Split-off from #566

This crate aims to generalize over in-place and buffer-to-buffer modes of operation and it's designed to be used in our cipher crates, i.e. block/stream ciphers, block modes, AE(AD)s.

[newpavlov]

@steffahn
I have the following question, if you don't mind. Is it safe to define get_in/get_out methods on InOut like this?

pub fn get_in<'b>(&'b self) -> &'b T {
    unsafe { &*self.in_ptr }
}

 pub fn get_out<'b>(&'b mut self) -> &'b mut T {
    unsafe { &mut *self.out_ptr }
}

[steffahn]

It's been a while since I last looked at this. It should probably be safe.

To determine safety, there's two concerns:

• Does the code break any invariants for references/pointers, i.e. is is just plain always-UB? (E.g. aliasing mutable references, or invalidating pointers, etc...)
  • On this point, the methods seem very straightforward, so I don't see any danger
• Does the method offer a sound API? (I.e. are all the lifetimes right, is there some tricky way to abuse it, etc.) On this front, I think that remembering my proposed alternative-implementation helps. If InOut<'a, T> was just an enum { Same(&'a mut T), Separate(&'a T, &'a mut T) }, would the API be possible to implement in safe code? If that's true for all the API surface (perhaps ignoring things like from_raw), then it is for sure sound.
  • Trying this approach here does work (at least for those two methods, feel free to test if the remainder of the API does fit the same model), so all seems sound.