Define library registry interface for external extension support

[aalpar]

Context

Three TODO comments in environment/top_level_environment.go identify unresolved design questions about the library registry:

• Line 68: TODO: consider defining an interface for library registries
• Line 375: TODO: review whether libraryRegistry should be copied here
• Line 376: TODO: review for optimization/refactoring opportunities

Problem

The library registry is currently a concrete type tightly coupled to TopLevelEnvironment. This blocks the P1 External Extensions plan (plans/EXTERNAL_EXTENSIONS_PLAN.md) because external extensions need to register libraries through a public interface, not by reaching into internal types.

Key questions to resolve:

1. Should libraryRegistry be an interface so external packages can provide custom implementations?
2. When creating child environments (NewChildTopLevelEnvironment), should the registry be shared (reference) or copied? This affects library isolation between embedded engines.
3. Are there optimization opportunities in the current registry lookup path?

Suggested approach

Define a LibraryRegistry interface in environment/ with methods for register, lookup, and list. TopLevelEnvironment holds an interface value instead of a concrete struct. External extensions implement the interface to provide custom library sources.

Related

• plans/EXTERNAL_EXTENSIONS_PLAN.md (P1 priority)
• TODO.md — External extensions item