Emitter framework refkey reform

### Clear and concise description of the problem

Presently the emitter framework defaults refkeys to simply `refkey(type)`, which is quite presumptuous - other declarations may want such a refkey. The emitter framework should use its own internal refkeys to track declarations it knows about similar to the [Zod emitter](https://github.com/bterlson/typespec-zod/blob/main/src/components/ZodSchemaDeclaration.tsx#L16).

Additionally, it should be possible to provide a mapping of Type -> Children to use in situations where a particular type has an existing declaration or you want to use a built-in type instead. This would allow using e.g. `InterfaceDeclaration` even in situations where an interface member has a type which is provided by some external library. Perhaps just a static list is sufficient, but otherwise the mapping can be stored in context. The static list might look like:

```ts
import { registerKnownType } from "@typespec/emitter-framework/typescript";
import { mcpSdk } from "./externals/mcpSdk.js";
import "@typespec/mcp/typekit";

// maybe in $onEmit:
registerKnownType($.mcp.builtin.ImageResult, mcpSdk["./types.js"].ImageResult);
registerKnownType($.mcp.builtin.TextResult, "string");
```

This would work such that a TypeSpec type like:

```tsp
model Thing {
result1: TextResult;
result2: ImageResult;
}
```

When passed to `InterfaceDeclaration` would produce:

```ts
import { ImageResult } from "@modelcontextprotocol/sdk/types.js";

interface Thing {
result1: string;
result2: ImageResult;
}
```

### Checklist

- [x] Follow our [Code of Conduct](https://github.com/microsoft/typespec/blob/main/CODE_OF_CONDUCT.md)
- [x] Read the [docs](https://typespec.io/docs/).
- [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.