feat: Add `flecs_matchbox` integration

[no-materials]

This PR introduces flecs_matchbox, a new integration crate for the Flecs Entity Component System, a high-performance C/C++ ECS with excellent Rust bindings.

The API is designed to be consistent with bevy_matchbox, offering a familiar developer experience. It provides:

• A FlecsMatchboxSocket component that is managed as a singleton.

• OpenSocketExt and CloseSocketExt traits on the Flecs World for ergonomic setup and teardown.

• An optional signaling feature for an embedded server on native builds.

The crate includes a suite of examples (hello, hello_host, hello_signaling) that mirror the existing bevy_matchbox examples to ensure correctness and demonstrate usage.

[johanhelsing]

Thanks for the PR! Implementation looks solid and well documented.

It makes me think a little bit about the organization of the project though. So far, we've done everything in a monorepo, even though some parts would arguably be cleaner to have separate and/or release separately. Right now we are tightly linked to Bevy's release cycle, which is fine for me, since it's the use case i care most about, and we should release regularly anyway.

Not sure how often flecs release breaking versions?

Just thinking aloud here.

[no-materials]

Thanks for the PR! Implementation looks solid and well documented.

It makes me think a little bit about the organization of the project though. So far, we've done everything in a monorepo, even though some parts would arguably be cleaner to have separate and/or release separately. Right now we are tightly linked to Bevy's release cycle, which is fine for me, since it's the use case i care most about, and we should release regularly anyway.

Not sure how often flecs release breaking versions?

Just thinking aloud here.

Thanks for the review! I'm glad you think the implementation is solid.

You've raised a valid point about the monorepo organization and release cycles. After you mentioned it, I did a deeper dive, and you are absolutely right to be cautious.

I found that the flecs-rust bindings are explicitly in an alpha/experimental stage, and the core flecs library itself has a history of breaking changes even in minor versions. This is a very different stability profile from bevy, and it would be a mistake to tightly couple the matchbox workspace to that.

With that in mind, how would you feel about this approach to isolate the risk?

• Independent Versioning: We manage flecs_matchbox with its own version number within the workspace, completely decoupled from bevy_matchbox's releases.

• Optional Feature Flag: We put the entire flecs_matchbox crate and its inclusion in the workspace behind a root-level feature flag (e.g., flecs). (Maybe this is to overprotective)

This way, matchbox can officially house the integration and make it discoverable for the flecs community, but without taking on the maintenance risk of a rapidly evolving dependency.

I am happy to handle the work of updating flecs_matchbox when the flecs rust bindings have breaking changes.

Let me know what you think. I'm keen to find a solution that works well for the project long-term.

[johanhelsing]

@no-materials are you still interested in this? Will make a release tomorrow probably. Not sure if I should include this or not.