`#[borsh(skip)]` should ask for `Default` implementation on the field's type, rather than its type parameters

[DanikVitek]

Current behavior

For a code like this:

#[derive(BorshDeserialize)]
enum I1<K, V, R> {
    B {
        #[borsh(skip)]
        x: HashMap<K, V>,
        y: String,
    },
    C(K, Vec<R>),
}

the generated BorshDeserialize implementation looks like this (path prefixes removed for readability):

impl<K, V, R> BorshDeserialize for I1<K, V, R>
where
    K: BorshDeserialize,
    R: BorshDeserialize,
    K: Default,
    V: Default,
{
    fn deserialize_reader<R: borsh::io::Read>(reader: &mut R) -> Result<Self, borsh::io::Error> {
        let tag = <u8 as BorshDeserialize>::deserialize_reader(reader)?;
        <Self as borsh::de::EnumExt>::deserialize_variant(reader, tag)
    }
}
impl<K, V, R> borsh::de::EnumExt for I1<K, V, R>
where
    K: BorshDeserialize,
    R: BorshDeserialize,
    K: Default,
    V: Default,
{
    fn deserialize_variant<R: borsh::io::Read>(reader: &mut R, variant_tag: u8) -> Result<Self, borsh::io::Error> {
        let mut return_value = if variant_tag == 0u8 {
            I1::B {
                x: Default::default(),
                y: BorshDeserialize::deserialize_reader(reader)?,
            }
        } else if variant_tag == 1u8 {
            I1::C(
                BorshDeserialize::deserialize_reader(reader)?,
                BorshDeserialize::deserialize_reader(reader)?
            )
        } else {
            return Err(borsh::io::Error::new(
                borsh::io::ErrorKind::InvalidData,
                format!("Unexpected variant tag: {:?}", variant_tag)
            ))
        };
        Ok(return_value)
    }
}

Meanwhile, HashMap<K, V> does not require the Default implementation for its type parameters, and yet, the implementation for BorshDeserialize does.
So rather than generating

K: Default,
V: Default,

bound, it should generate

HashMap<K, V>: Default

bound. Same goes if the field would be of any other type, e.g. Option<T> or Vec<T>, as those types do not require Default to be implemented for their type parameters
This can be fixed and released as a patch, because the existing API would not be reduced, but broadened in applicability.

[dj8yfo]

@DanikVitek i've thought about this a bit. I guess the optimal implementation would be to:

1. still place Default bounds on type parameters themselves, not OpaqueFieldType<T1, T2, T3>. This way it would be still easy to see in expansion and to figure out the actual bounds on input type parameters without diving into code of OpaqueFieldType and possibly other types in a chain -> OpaqueType2 -> OpaqueType3 (i mean, if everyone followed this pattern of deferring figuring out bounds to compiler).
2. add mentioned std collections to exceptions, where no Default bounds will be added to their type parameters during derive: HashMap, Vec, Option, BTreeMap. This would be a syntactic distinction, so anyone reusing these names for their non-std types would encounter the same behaviour. Add documentation about these exceptions to Bounds anchor of BorshDeserialize rustdoc page.
3. current behaviour is consistent with what compiler derives for new types, so at least there will be no skew here:

#[derive(Default)]
struct A<X, Y, Z> {
    x: X,
    y: Y,
    z: Z,
}

#[automatically_derived]
impl<
    X: ::core::default::Default,
    Y: ::core::default::Default,
    Z: ::core::default::Default,
> ::core::default::Default for A<X, Y, Z> {
    #[inline]
    fn default() -> A<X, Y, Z> {
        A {
            x: ::core::default::Default::default(),
            y: ::core::default::Default::default(),
            z: ::core::default::Default::default(),
        }
    }
}