Allow Paths as type names for instantiation.

[faultyserver]

This issue has been marked as a "Good First Issue"! If you'd like to tackle this issue as your first contribution to the project, be sure to read the Get Involved section of the README for some help with how to get started.

Right now, the parser isn't able to understand type names for instantiations that include a namespace. For example, something like this:

%IO.FileDescriptor{}

would fail to parse, where the parser is expecting the opening curly brace after IO, rather than the dot that is actually given. A quick workaround for this is using a ValueInterpolation for the type, but I feel like this should be something that will be a common use case, and should be supported naturally.

This should be fairly simple to implement. Right now, the parser just checks for a single token for the type name:

myst/src/myst/syntax/parser.cr

Lines 990 to 998 in 52314de

	type =
	case current_token.type
	when Token::Type::CONST
	token = current_token
	read_token
	Const.new(token.value).at(token.location)
	else
	parse_value_interpolation
	end

Instead, it should use a loop, checking for a CONST token, then also checking if the next token is a POINT. If it is, repeat the loop, otherwise break from the loop. This behavior was actually already implemented recently in the parse_type_path method, and should be re-used here instead of the case shown above.

However, parse_type_path will also need a little modification to move the ParseError about supertypes into parse_type_def rather than that method itself. This will require adding a check on current_token.type in parse_type_def as well. Once that is removed, parse_type_path should be good to go for use here with instantiations.

For specs, there's an existing section of tests around using a ValueInterpolation for the type name. A few similar specs should be added for using a namespaced type path as the name.

As always, if you have any questions, feel free to ask here or on Discord :)