Don't automatically derive BundleFromComponents with Bundle

[alice-i-cecile]

Instead of making BundleFromComponents opt-out, though, would it make sense to have it be opt-in and require #[derive(Bundle, BundleFromComponents)]? That better matches the general convention that a derive only implements a single trait. And if you do need to call take, the trait bound should help guide you to derive the second trait.

Originally posted by @chescock in #19249 (review)

[Wuketuke]

wrote some code for that in my fork but i havent made a pr yet, because I want a thumbs up if this is the correct direction

i eliminated duplicate code by creating a function that handles all the syntax tree processing, and then accepts a FnOnce that does the actual implementation

active_field_types used to be a double reference, but i had to call clone because rust do like self referential structs. Thats the main reason i am unsure about how i did this

i havent changed anything really about the logic, just moved some code around

[alice-i-cecile]

@SkiFire13 may have a more informed opinion on that :)

[SkiFire13]

@Wuketuke you could make BundleInfo hold references if you want to avoid the clone, although that's not really necessary. Personally I don't particularly like the closure API (I would prefer to just have a constructor returning Result<BundleInfo, TokenStream>), but that's just a nit.

I think the most important question is if we want a bazillion derive macros or if we instead prefer specializing the existing ones with ad-hoc options. I'm not sold on the "one derive macro per trait" approach, as it makes very easy to have long lists of traits to derive, and most importantly has the wrong "default", i.e. I would prefer deriving BundleFromComponents be the default with an opt-out for the few cases where it's not possible, but splitting the derives essentially makes it opt-in.