✨ feat: add a new `bs.components` module

[theogiraudet]

Tasks to do before merging

• [x] I accept to publish my contribution under MPL v2 License
• [ ] My pull request is linked to an existing issue
• [ ] I have added my contribution to the changelog
• If my pull request is a new or modify an existing feature:
  • [ ] I have documented my contribution (/docs)
  • [ ] I have added or updated the header of the features' root function I contribute
  • [ ] I have tested my contribution

[theogiraudet]

@aksiome Before implementing, I would like feedback on what I plan to do (cf documentation).

[theogiraudet]

Summary of the discussion:

• Remove all entity specific properties except the required ones
• Group/merge related properties
• Callback should be optional when component is stateful
• selected or select, propose both?
• click_button=left|right for on_click
• Radio button → radio
• check for checkbox?
• edit → update
• Add ID to radio
• way to easily get the state for a group

[aksiome]

After thinking more about the size-related issues, I believe I've found a way to significantly reduce the complexity.

What if we create functions like make_button, make_checkbox, etc., that are designed to run on already summoned entities? Each entity type can have its own specific implementation, with a fallback for others. This allows users to summon the entities and the command only adds GUI-like behavior. For example, we could use passengers for display entities but not for mobs. The only potential issue is if we need parameters that differ by entity type, but I don't think that’s necessary. What we mainly need is different default behavior per entity type. This approach also means users are responsible for setting the appropriate size when creating the button.

For radios, I remember there was an issue about using a string ID for the group to avoid manually creating a group, but I can't recall exactly why.