[red-knot] Emit an error if a bare Annotated or Literal is used in a type expression

[AlexWaygood]

Summary

These are both invalid annotations (the special forms must be parameterized -- Literal requires at least one argument, and Annotated at least two) but we currently don't emit errors on them:

from typing import Literal, Annotated

x: Literal
y: Annotated

This PR fixes that by modifying Type::in_type_expression to return a Result. The Ok variant of the result is a Type, and the Err variant is an error struct that wraps:

• the necessary information for emitting a diagnostic from the TypeInferenceBuilder
• the type that we should fallback to in the event of an error

Test Plan

New mdtests added, and TODOs in existing mdtests have been fixed.

[AlexWaygood]

I moved this file from resources/mdtest/literal/literal.md to resources/mdtest/annotations/literal.md. That's where I expected to find it -- the other tests in the resources/mdtest/literal folder are all to do with checking we accurately infer types for objects created using Python literals -- ast::Dict expressions, etc.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[carljm]

Nice!

[carljm]

I feel like I slightly prefer the pattern we use in CallOutcome etc, where we have a method on the result type (or could just be on the error variant) that takes in a DiagnosticsBuilder and a node and emits the right diagnostics, returning the fallback type. This makes handling the result a bit more ergonomic (though you do have to explicitly pass in the diagnostics builder), and it prevents proliferating infer_* methods in TypeInferenceBuilder (which is already too large) that don't really fit the pattern of "infer a type for an AST node."

I realize this means passing AST nodes into types.rs, but I see the result/outcome types as kind of an intermediate layer between type inference builder and Type operations, that brings together nodes, diagnostics, and type operation results. I already moved CallOutcome out of types.rs; we could move more of those result/outcome types out of types.rs to clarify this layering.

This is all kind of musing, though; open to arguments for the pattern you used here.

[AlexWaygood]

I do feel like a Result works really well here. There really are only two possibilities -- either it's okay, and we don't need to emit a diagnostic, or it isn't, and we do. If I were to write a custom *Outcome-like enum here, I think it would end up looking exactly like Result, so reinventing the wheel feels a little silly. And I just don't know what I'd call the enum 😆

But I totally take the point that the logic for unwrapping the error struct into a type (and emitting a diagnostic in the process) doesn't need to be on the TypeInferenceBuilder. I've moved it into an InvalidTypeExpressionError::into_fallback_type() method instead. I agree it's much nicer that way, and means we'll be able to easily move the enum into another submodule in the future if we want to.