Add required bounds to derived impl

[JustusFluegel]

This is an attempt to make the derive macro for Diagnostic work better with generics, allowing to write code like for example

#[derive(Debug, thiserror::Error, miette::Diagnostic)
enum MyError<T> {
     #[error(transparent)]
     #[diagnostic(transparent)]
     Other(#[from] T).
     #[error("bar")]
     #[diagnostic(help = "baz")]
     Foo
}

This should for example make #162 just work, as well as things like

#[derive(Debug, thiserror::Error, miette::Diagnostic)
struct MyOtherError<T> {
     #[label]
     label: T
}

and the other supported attributes.

AFAIK the only gotcha with this implementation right now is that #[related] only works with concrete collection types and not with generic collections, but the type inside the collection can be generic. (meaning: Vec<T> works but not any arbitrary C where C: IntoIter<Item: Diagnostic>), and I think that is a current limitation of the rust compiler / the current Diagnostic trait design.

Questions: Do we want to gate this behind a feature flag since it pulls in extra-traits from syn and performs a bunch of extra work?

[JustusFluegel]

This should be mostly good, I'll add some tests but I'd appreciate a comment-type review in the meantime if possible :)

[JustusFluegel]

ok tests are now there as well (thought I would do it later but I noticed
i had some extra time on hand so I did it now), I am sure there are some things I should change since this is a pretty big pr and I am not that familiar with this project but from my perspective this should be finished apart from that.

[JustusFluegel]

Oh and I just noticed since I added an explicit to_owned instead of just relying on an implicit copy for the label (I think, should test, maybe add a unit test for that?) #377 should work just fine as well. Since Copy ⊂ Clone ⊂ ToOwned this shouldn't actually be breaking (?), and make the derive strictly more flexible (although might be worth to check if that is actually the case)

[zkat]

Putting it behind a feature flag seems wise, yes.

[JustusFluegel]

Hi, as I am in the process of moving right now I will probably only get back to this the next weekend or so, but my current plan for this is:

• Add the suggested feature flag ( I would probably name it perfect_derive which aligns with other work on the same idea across the ecosystem )
  • Since we don't add bounds to the impl at all right now this should be a purely additive feature, which is what all feature flags should be
• Write a higher level summary on the changes of this pr
  • explicitly list all the codegen changes inside the derive macro ( to make it easier to spot accidental breaking changes in review, even though I didn't mean to introduce any )
  • summarize how this feature actually works
• Add docs to document the feature flag in more detail on both docs.rs as well crates.io ( if applicable )
• fix the ci breakages
• and, since I thought a bit more about the changes I did here I think I found a few ways to simplify things that I am then also going to do while I am at it :)

And finally, after all this is done I should probably prepare a change log entry, so I am going to do that as well.

If that sounds like a reasonable plan feel free to let me know what you think (or any other things I should do) otherwise I would just go ahead with that plan once I've got some more time to work on this ( as I've mentioned probably around next weekend )

[JustusFluegel]

( accidentally pressed the close button, sorry for the noise )