feat: PackageSources — compile a project from in-memory strings

[Kinflou]

The playground needs core to compile a project without a filesystem. compile_package reads config.<ext> and globs src/**/*.ids; this adds the in-memory twin, sharing one interpretation pass so the two can't drift.

API

let context = PackageSources::new()
    .config(config_idp_src)              // optional — a minimal congregation is synthesised
    .schema(["chat"], chat_src)          // namespace segments + source
    .schema(["chat", "admin"], admin_src)
    .compile()?;                         // -> Result<ProjectContext>

• Namespace = the segments you pass — which is exactly what the on-disk layout derives from a file's path under src/. Structure comes from layout (Rust-module style), not a keyword in the file.
• .config is optional — when omitted, a minimal congregation (congregation playground / specification_version = 1 / rust#1.70.0) is synthesised, so "paste a struct, get Rust" is one call.
• The returned ProjectContext has config_frozen set and a SchemaContext per schema — ready for codegen, same as compile_package.

Refactor

• The filesystem-free half of interpret_schemas is now interpret_schema_sources(&mut ProjectContext, &[(Vec<String>, String)]). compile_package (glob + read, then delegate) and PackageSources both use it — one interpretation + validation pass.
• Dropped the *const → *mut unsafe in interpret_schemas; it takes &mut ProjectContext now.
• config::Compile::from_source no longer has a panicking default (// TODO: Better error handling) — it's a required method; ProjectInterpreter delegates to the existing from_config_source (returns Result).

Tests

tests/package/from_sources.rs — 6: synthesised + explicit congregation, nested namespace segments kept, multi-schema all interpreted, cross-schema use resolves (qualified reference), a parse error is returned not panicked. Full suite green.

Cross-schema use works with a qualified reference (use types::User + field: types::User); a bare User after a single-symbol use is a separate, pre-existing core gap — unaffected here (same code path as on disk).