const/readonly assertion support for `Map` and `Set`

### 🔍 Search Terms

"as const", "as readonly", "const assertion", "keyed collections"

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Have a way to take an existing `Map` or `Set` and assert it to be its readonly variant without needing to repeat the generic types.

### 📃 Motivating Example

Today we can create maps (and sets) with explicit and inferred generic types but in order to make them readonly the generic types have to be explicitly written, sometimes repeated:

```ts
const exampleMap1: ReadonlyMap = new Map([["a", 1], ["b", 2]]);
const exampleMap2: ReadonlyMap = new Map().set('a', 1).set('b', 2);
```

With something like const assertion support for `Map` (and `Set`) we'd be able to get readonly maps and sets without repeating the generic types:

```ts
const exampleMap1 = new Map([["a", 1], ["b", 2]]) as const;
const exampleMap2 = new Map().set("a", 1).set("b", 2) as const;
```

### 💻 Use Cases

1. What do you want to use this for? I want to use this for creating keyed collections that will be used elsewhere and I want to avoid modifications. (Note: this won't prevent runtime modifications but the same is true for const assertions on arrays and objects today.)
2. What shortcomings exist with current approaches? Repetative generic types and verbose code to make a keyed collection readonly.
3. What workarounds are you using in the meantime? Repeating the generic types and explicitly defining things as readonly keyed collections.

Start by reviewing the TypeScript const assertion behavior for arrays and objects and the existing Map and Set type-checking rules. Determine how readonly keyed collections should be represented without repeating generic types, then add coverage showing that the proposed assertions infer readonly Map and Set types while preserving current JavaScript output.

Written by the indexing model from the issue text.