Add Model type to Cadl.Reflection

[pshao25]

Description:
We have such decorator to be added:

extern dec exclude(target: Model);

However, Model is not in the Cadl.Reflection

Details:
Discussion is in #1524. To me object give the impression it represents everything. So I would recommend adding Model into Cadl.Reflection.

[nguerrera]

Proposal

TL/DR: Add model Model and model Scalar to Cadl.Reflection, and nothing more at this time.

Add

The following type kinds are missing and should be added to Cadl.Reflection for the reasons below.

• Scalar: Missing scenario to be able to express "this decorator applies to scalars".
• Model: Technically expressible using object (*), but too confusing.

Keep out

The following type kinds are not in Cadl.Reflection and should be left out:

• NumericLiteral/StringLiteral/BooleanLiteral: Use numeric (or more specific), string, or boolean instead. (*)

• Tuple: Use more specific type like dec example(target, arg: [Type, string]) (*)

• ObjectType: Use object (*)

• FunctionType, IntrinsicType, FunctionParameter, Projection: No scenarios yet.

Keep out all-encompassing generic Type as well

We also don't need Cadl.Reflection.Type. It's a bit of compiler trivia that all of these things are "types" and I think unknown is more intuitive to say this can be anything, at least until we tackle values vs. sub-types. (*)

Already in

The following type kinds are already matched in Cadl.Reflection: no change.

• ModelProperty
• Interface
• Enum
• EnumMember
• Namespace
• Operation
• Union
• UnionVariant

(*) Values vs. subtypes

This proposal still entirely punts on the distinction between "value of type" and "subtype of type" which we cannot express. We only have a concept of the latter and get by using literal subtypes as "values". This has some edges like being able to pass the type string to a decorator that takes a string arg. This issue is still tracked separately by #888

This proposal aims to make a minimal change that addresses the common feedback of not finding how to express "this decorator only applies to models". And it turns out that "this decorator applies only to scalars" is equally valid so it proposes to address that too. The rest is still left for #888 to sort out.

[nguerrera]

Approved.

Note important observation made during review. object and Model will not be 100% equivalent since a union of models would be assignable to object but not to Model. This should fall out naturally, but we should test to be sure.

Implementation issue: #1655