derive(Component) and bundles

If components are an opt-in component via some derive(Component) macro we could also have the derive spit out a trait impl for Bundle too. This would make every component be a one element bundle.

Now if everything is a bundle we can remove insert_bundle remove_bundle and just have only insert and remove that works off a T: Bundle bound as it would include both "components" and bundles.

without derive(Component) if you do .insert(Bundle { … }) you silently get wrong behaviour
with derive(Component) you get a compile error
with this it compiles and works exactly how you would expect it to work

@frizi said that we have a #[bundle] attribute for our derive(Bundle) macro which allows us to let our bundles contain nested bundles as fields, but if every component is a bundle we can get rid of that attribute and just pretend its on every field because every field is a bundle now.

both of these seem like pretty clear ergonomic wins, question I guess is whether people would find .insert(Bundle { .. }) to be unintuitive