feat(plugin): widen the RPC surface to LibraryInstaller-based plugins

An installer that extends LibraryInstaller reaches for the Composer object
graph in ways the proxy did not answer: the download manager and the config,
the writable repository methods, a React promise as its own return value, and
`new Package(...)` from its supports() path.

* `Composer::getConfig`/`getDownloadManager` are dispatched, and both classes
  become generated proxy stubs. Their reads and mutators answer from the Rust
  entity; the surfaces needing stubs of their own (ConfigSourceInterface,
  DownloaderInterface) stay explicit errors.
* The download manager's futures are driven to completion and handed back as
  already-settled React promises, since PHP declares a non-nullable
  PromiseInterface there. A promise a plugin returns is drained the same way:
  settled yields its value, rejected re-raises, pending is an explicit error.
* Proxy stubs now carry the real class's constructor and ask the Rust side to
  allocate the entity; reviving a stub for an existing entity binds the handle
  without running it. Classes Rust cannot build name themselves in the error.
* The package proxy covers `Package`'s own setters, `CompletePackage`'s
  metadata, `RootPackage`'s root-only state, and `BasePackage::$id`.

Link values and release dates still have no wire image, so the methods
carrying them remain explicit errors.

0 files changed, 0 insertions, 0 deletions