Introduce 'extends type' and 'extends modifier' or phantom types to simplify the language and speed it up.

Basically when using [k in keyof] and mutating structures in ways that can be found at these repositories it becomes apparent that to simplify the learning cure it would be better if the type modifiers such as optional/required/undefined/readonly|null can be accessed and interrogated separately from the type and modifiers mashed together..
So one can focus on writing a routine that would iterate the type to be integorate for the architectural structure/shape if to call it that, which allow one to write super fast simple methods to recursively no the difference between Record<string,any>, Array, never, unknown. instead of having to do the following: T extends Record<string,any> | undefined | readonly | null ? then recuse, else step over.

The following type integogation operators.

1. extends ? mix of the type and modifiers
2. extends type ? just the base type without any modifiers (can only be single type else undefined)
   so string | number = undefined, string = string, number = number, array = array, record = record, class = class, constructor = constructor, one needs to be able to differential record, which is interface from Date so require have a phantom type if the interface was generate from a class or something the features a constructor. Otherwise one will iterate into custom types like Date, which is a problem.
3. extends modifiers ? Which just allows evaluation of modifiers. hopefully not a list in the backend implementation of the compiler code, hopefully just true and false flags for speed

Phantom types

Maybe just implement the concept of phantom symbols, that don't actually exists, were by optional/required, nullable, readonly, type can be access like :
T[PT.Required] extends true ? ..
T[PT.Nullable] extends true ? ...
T[PT.Readonly] extends true ? ...
T[PT.Type] extends true ? ...
T[PT.Cusom] extends true ? ... // For passing other information that doesn't exist to validate typings.
allow one to create the own phantom types, which information we will pass onto for downstream validation in some complex situations like Mongoose Update Statement validation which has 3 parts.

Work around Mongoose Update Statment

Work around Mongoose Types

https://github.com/Microsoft/TypeScript/issues/28699

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Inizia leggendo gli operatori e il modello di tipo fantasma proposti in questa issue, quindi confronta gli esempi Mongoose collegati e la issue correlata #28699. Identifica i punti di ingresso del compilatore TypeScript per i tipi condizionali e i modificatori di tipo prima di definire il comportamento previsto per unioni, record, array, classi e metadati fantasma personalizzati. Il lavoro sarà completato quando saranno definiti un design condiviso e i corrispondenti test del compilatore.