Allow filtering for what types get a trait derive

[Exotik850]

Currently, using with_derive on the Config struct tries to derive every trait given on every type that is generated with the renderer. This causes an issue for larger schemas where some types cannot derive traits that others can, e.g.

Config::default()
     ...
     .with_derive(["Default"])

for my quickbooks-xsd crate generates the following code for enums:

#[derive(Default)]
pub enum InvoiceTypeContent {
   PrivateNote(String),
   Id(String),
   ...
}

Which fails to compile since there is no #[default] attribute on the enum to specify a default

One solution to this could be adding a filter of sorts to the derive step, allowing for users to specify what criteria is needed to derive a trait

e.g.

pub enum TypeFilter {
    All,
    Custom(Box<dyn Fn(&DataType, &Context) -> bool>)
}
pub struct DeriveFilter {
     derives: Vec<String>,
     filter: TypeFilter
}

replacing the derives in the RendererConfig with the DeriveFilter type and updating the code accordingly, and adding a with_derive_filter function like so:

impl Config {
   fn with_derive_filter(mut self, filter: DeriveFilter) -> Self {
      self.renderer.derive.push(filter);
      self
   }
}

This would allow users to easily configure what traits are implemented for specific types, in theory this would allow for better fine-grained control for traits like Copy and Default that cannot be trivially derived for every type

[Bergmann89]

Hey @Exotik850,

we already have a solution for this: See DataType::derive, but other than other features this is not reachable through the Config, you have to drive the pipelines manually and once you got the DataTypes from the Generator you can manually browse the type and set what traits you want to derive.

If you want to, I can add an example to the code base to make it more visible, but I wouldn't export it through the Config because I would like to keep the config relatively simple and free from type-to-X maps. Also error handling for missing types will be hard through the config. It's more flexible to just implement the glue code between the different pipeline steps yourself in this case.

Best, Bergmann :)