Incorporate type names into Bicep symbol table

[jeskew]

Resolves #8811

This PR adds array, bool, int, string, and object as properties to the sys namespace and updates the NameBindingVisitor to look for type symbols on imported namespaces when resolving the symbol to which a name refers.

This change allows for some simplification in the parser, as the parser does not need to distinguish between SimpleTypeSyntax (for ARM primitive types), TypeAccessSyntax (for user-defined types), and VariableAccessSyntax (for all other identifiers that are assumed to correspond to a defined symbol). Instead, VariableAccessSyntax is used for all three cases. Most lines changed in this PR are updates to main.syntax.bicep baseline files in which SimpleTypeSyntax is being replaced with VariableAccessSyntax.

There are two breaking changes that would result from merging this PR:

1. If a template defines a symbol that masks an ambient type, the masked type can only be accessed with a namespace-qualified expression. E.g., param string string is legal today, but with this change, it would need to be expressed as param string sys.string.
2. It's currently permitted to overwrite a built-in namespace using an import statement. Doing so already removes any functions or decorators defined in the namespace, and with this change, it would also remove all types defined in the namesapce. For example, import 'az@1.0.0' as sys (without an aliasing import of the sys namespace in the same template) already blocks the use of most decorators and functions, but with this change, it would also block the use of string, int, bool, array, and object.

Microsoft Reviewers: Open in CodeFlow

[jeskew]

I am not good at naming things 😞. This class exists so that NamespaceType can enforce that all of its properties are themselves types, which is represented as a TypeType (another name that could probably use some work).

[majastrz]

I don't mind the names, but would be good to add comments on the classes to describe what they represent.

[majastrz]

[majastrz]

I didn't try the build, but I have some questions:

• Do we need to update any of the completions logic? For example, will sys.| completions show the types that are available?
• Does go to def, find refs, rename, and highlights all work as expected with types?

[jeskew]

I didn't try the build, but I have some questions:

• Do we need to update any of the completions logic? For example, will sys.| completions show the types that are available?
• Does go to def, find refs, rename, and highlights all work as expected with types?

Go to def, find refs, renaming, and highlighting work as expected. You can't go to the definition of sys.*, but that's in line with how go to def works with functions.

The completion logic added in the PR kicks in when the user is in a location that expects a type expression, and any masked ambient types are added to the completions list as fully qualified references. sys.| relies on the existing property access completion, which could be specialized a bit so that type completions don't show built-in functions and value completions don't show ambient types: