Allow the use of `core` components and concepts in user-defined concepts

[philpax]

At present, concepts are restricted to using components / extending concepts defined in the same ambient.toml. The API macro crate includes the core ambient.toml, so it should be able to draw upon it to find components and concepts to use if not defined in the current project.

This needs to:

• resolve the paths to the components and concepts from the core module correctly
• work with existing use-cases
• not import those concepts into scope
• be implemented in such a way that it could be extended to support using components/concepts from project dependencies (#23) in future.

[gautamprikshit1]

https://github.com/AmbientRun/Ambient/blob/main/guest/rust/api/api_macros/src/ambient_project/concepts.rs#L15

Just to confirm, I need to import the ambient.toml file in this check and extract the concepts

[philpax]

Not quite - this is a two-part problem. The ambient_project::implementation function reads in a manifest, generates a tree of components (all components defined by the manifest, as organised by its namespaces), and generates code for both the components and the concepts defined by the manifest. The concept-generation step takes the tree that was generated and uses that to look up which components are in scope.

ambient_api_macros contains the core ambient.toml, which describes the core components and concepts for the runtime. This is loaded by the api_project macro, which is used only by the ambient_api crate. The main macro is what users use, and for this issue, it also needs to load in the core ambient.toml and read the components and concepts from that.

It needs to do that in such a way that the core ambient.toml's components and concepts are available for people to use in their own concepts, but are not added to the generated output.

There's quite a few nuances here (especially around generating the correct IDs for components), so I think I'll take it off good first issue for now.