Implement legacy TypeScript decorators and metadata with native NestJS acceptance

Existing NestJS applications use TypeScript's legacy decorator semantics (experimentalDecorators) and emitted design-type metadata. scriptc currently adopts neither option and supports only a restricted subset of newer class decorators. Issue #238 reports the resulting constructor-parameter decorator refusal.

Implement a coherent legacy decorator pipeline that preserves the original TypeScript checks and lowers decorations to existing native calls, objects, and property descriptors. Keep the current newer-decorator behavior intact and avoid changing code generation for programs that do not use legacy decorators.

Acceptance:

• Class, property, method, accessor, constructor-parameter, and method-parameter decorators, including static members, factories, generic standard decorator signatures, descriptor changes, and permitted replacements.
• TypeScript-compatible expression evaluation, application, static-initialization, inheritance, and class-binding behavior.
• emitDecoratorMetadata design types, parameter types, and return types, including imported runtime types, erased types, type-only imports, and forward-reference behavior.
• Actual reflect-metadata package execution with stable constructor/prototype/method identity and own/inherited lookup behavior.
• A pinned real NestJS example that builds to native code and exercises dependency injection, an HTTP success response, a missing route, and clean shutdown. Do not substitute framework stubs or Node-island execution.
• Differential tests using TypeScript-emitted JavaScript under the pinned Node oracle, diagnostic and module-order baselines, per-program CI costs, zero-cost validation for unaffected programs, and the repository's plain and sanitized gates.

This is the implementation and acceptance work associated with #238; retain precise limitations wherever the surrounding native object model still requires an explicit diagnostic.