Prepare 2.0.0

[quininer]

Due to new requirements, I tried to make a derive proc macro and found some previous unreasonable designs.

1. Null is not suitable for Option<T> because it cannot distinguish Option<Option<T>>

   cbor4ii/src/core/dec.rs

   Lines 738 to 749 in 01b3c1f

   	impl<'de, T: Decode<'de>> Decode<'de> for Option<T> {
   	#[inline]
   	fn decode<R: Read<'de>>(reader: &mut R) -> Result<Self, Error<R::Error>> {
   	let byte = peek_one(&"option", reader)?;
   	if byte != marker::NULL && byte != marker::UNDEFINED {
   	T::decode(reader).map(Some)
   	} else {
   	reader.advance(1);
   	Ok(None)
   	}
   	}
   	}

2. The W generic constraint of encode is on the method rather than trait, which makes the trait unusable as a dyn object. I actually thought about this, we could do impl<W: Write, T: Encode> DynEncode<W> for T, but this is not convenient.

   cbor4ii/src/core/enc.rs

   Line 22 in 01b3c1f

   fn encode<W: Write>(&self, writer: &mut W) -> Result<(), Error<W::Error>>;

3. The want in Read::fill is not mandatory. I designed it thinking it could be used as an optimization, but I don't believe anyone does that. We can remove it.

   cbor4ii/src/core/dec.rs

   Line 27 in 01b3c1f

   fn fill<'short>(&'short mut self, want: usize) -> Result<Reference<'de, 'short>, Self::Error>;

   Furthermore, we should deprecate fill and move peek_one and pull_exact directly into Read trait, so that SliceReader has less overhead.

4. I used &&str to save the size of Error type, but we could have just used u8 as error kind.

   cbor4ii/src/core/dec.rs

   Line 347 in 01b3c1f

   let name = &"u128";

Despite my thoughts, I don't think 2.0.0 will happen anytime soon, and it shouldn't have any impact on serde users.