Derive Default for structs when all field defaults are intrinsic

[danieleades]

Problem

When every property of a struct has a default and none of them are custom, the generated code emits a hand-written impl Default whose every field initializer is Default::default(). That impl is exactly what #[derive(Default)] produces, so clippy's warn-by-default derivable_impls lint fires on it in consuming code — roughly 50 times on the output for a large schema like the github.json test fixture. It also bloats the generated output.

Fix

In output_struct, when there is no whole-type default value and every property's default is the intrinsic Default::default(), add Default to the struct's derive set instead of emitting the manual impl.

Hand-written impls are kept where they carry real information:

• structs with a whole-type default value,
• structs where any property has a custom default function,
• builder-module Default impls (which initialize fields to Ok(..)/Err(..)).

Trade-offs

None behavioral — the derived impl produces identical values to the removed manual one. The golden-file diff is large but mechanical: every removed impl had all-Default::default() initializers, and its struct gains Default in the derive list.

[ahl]

This is an interesting schism. I can see the value in relying on the Default derive implementation, but I could imagine that compilation might be faster by having more code explicit with less generated on subsequent passes of macro expansion. In fact, I had been thinking that it might make sense e.g. to rely on serde_core rather than serde and expand Serialize and Deserialize implementations.

Certainly when everything is behind a macro, invoking another macro seems of limited benefit. In the case e.g. where we're generating a stand-alone crate, does it make sense to have the code be more idiomatic of hand-written code? More broadly, what utility does clippy provide for generated code? In many cases, striving for clippy cleanliness seems counter-productive.