refactor(core): rename ngDirectiveDef to ɵdir (#33110)

Directive defs are not considered public API, so the property
that contains them should be prefixed with Angular's marker
for "private" ('ɵ') to discourage apps from relying on def
APIs directly.

This commit adds the prefix and shortens the name from
ngDirectiveDef to dir. This is because property names
cannot be minified by Uglify without turning on property
mangling (which most apps have turned off) and are thus
size-sensitive.

Note that the other "defs" (ngFactoryDef, etc) will be
prefixed and shortened in follow-up PRs, in an attempt to
limit how large and conflict-y this change is.

PR Close #33110

packages/compiler/design/architecture.md

@@ -171,7 +171,7 @@ There are also a list of helper decorators that make the `@Component` and `@Dire
 
 Each of the class decorators can be thought of as class transformers that take the declared class and transform it, possibly using information from the helper decorators, to produce an Angular class. The JIT compiler performs this transformation at runtime. The AoT compiler performs this transformation at compile time.
 
-Each of the class decorators' class transformer creates a corresponding static member on the class that describes to the runtime how to use the class. For example, the `@Component` decorator creates a `ɵcmp` static member, `@Directive` create an `ngDirectiveDef`, etc. Internally, these class transformers are called a "Compiler". Most of the compilers are straight forward translations of the metadata specified in the decorator to the information provided in the corresponding definition and, therefore, do not require anything outside the source file to perform the conversion. However, the component, during production builds and for type checking a template require the module scope of the component which requires information from other files in the program.
+Each of the class decorators' class transformer creates a corresponding static member on the class that describes to the runtime how to use the class. For example, the `@Component` decorator creates a `ɵcmp` static member, `@Directive` create a `ɵdir`, etc. Internally, these class transformers are called a "Compiler". Most of the compilers are straight forward translations of the metadata specified in the decorator to the information provided in the corresponding definition and, therefore, do not require anything outside the source file to perform the conversion. However, the component, during production builds and for type checking a template require the module scope of the component which requires information from other files in the program.
 
 #### Compiler design
 

packages/compiler/design/separate_compilation.md

@@ -39,7 +39,7 @@ The mental model of Ivy is that the decorator is the compiler. That is
 the decorator can be thought of as parameters to a class transformer that
 transforms the class by generating definitions based on the decorator
 parameters. An `@Component` decorator transforms the class by adding
-a `ɵcmp` static property, `@Directive` adds `ngDirectiveDef`,
+a `ɵcmp` static property, `@Directive` adds `ɵdir`,
 `@Pipe` adds `ngPipeDef`, etc. In most cases values supplied to the
 decorator is sufficient to generate the definition. However, in the case of
 interpreting the template, the compiler needs to know the selector defined for
@@ -67,15 +67,15 @@ class:
 | `type`              | implicit              |
 | `isComponent`       | `ɵcmp`      |
 | `selector`          | `ngModuleScope`       |
-| `exportAs`          | `ngDirectiveDef`      |
-| `inputs`            | `ngDirectiveDef`      |
-| `outputs`           | `ngDirectiveDef`      |
-| `hostListeners`     | `ngDirectiveDef`      |
-| `hostProperties`    | `ngDirectiveDef`      |
-| `hostAttributes`    | `ngDirectiveDef`      |
+| `exportAs`          | `ɵdir`      |
+| `inputs`            | `ɵdir`      |
+| `outputs`           | `ɵdir`      |
+| `hostListeners`     | `ɵdir`      |
+| `hostProperties`    | `ɵdir`      |
+| `hostAttributes`    | `ɵdir`      |
 | `providers`         | `ngInjectorDef`       |
 | `viewProviders`     | `ɵcmp`      |
-| `queries`           | `ngDirectiveDef`      |
+| `queries`           | `ɵdir`      |
 | `guards`            | not used              |
 | `viewQueries`       | `ɵcmp`      |
 | `entryComponents`   | not used              |
@@ -86,8 +86,8 @@ class:
 | `componentFactory`  | not used              |
 
 Only one definition is generated per class. All components are directives so a
-`ɵcmp` contains all the `ngDirectiveDef` information. All directives
-are injectable so `ɵcmp` and `ngDirectiveDef` contain `ngInjectableDef`
+`ɵcmp` contains all the `ɵdir` information. All directives
+are injectable so `ɵcmp` and `ɵdir` contain `ngInjectableDef`
 information.
 
 For `CompilePipeSummary` the table looks like:
@@ -193,7 +193,7 @@ manually.
 The metadata for a directive is transformed by:
 
 1. Removing the `@Directive` directive.
-2. Add  `"ngDirectiveDef": {}` static field.
+2. Add  `"ɵdir": {}` static field.
 3. Add `"ngSelector": <selector-value>` static field.
 
 ##### example
@@ -213,7 +213,7 @@ export class MyDirective {
   constructor() {
     this.dirId = 'some id';
   }
-  static ngDirectiveDef = ɵɵdefineDirective({...});
+  static ɵdir = ɵɵdefineDirective({...});
 }
 ```
 
@@ -226,7 +226,7 @@ export class MyDirective {
     "MyDirective": {
       "__symbolic": "class",
       "statics": {
-        "ngDirectiveDef": {},
+        "ɵdir": {},
         "ngSelector": "[my-dir]"
       }
     }