Provide code analysis rule to detect if constraint is invalid for parameter type

[Alex-Sob]

This PR should address #45218

This PR is adding a new code analysis rule ASP0029: Invalid constraint for parameter type for Minimal APIs. The diagnostic should be reported if route constraint cannot be used with the type of the corresponding parameter declared in the route handler, for example:

app.MapGet("/{id:datetime}", (int id) => ...);
app.MapGet("/{id:alpha}", (int id) => ...);
app.MapGet("/{id:bool}", (int id) => ...);

Rule

Rule id	Title	Description
ASP0029	Invalid constraint for parameter type	The constraint '{0}' on parameter '{1}' can't be used with type '{2}'

The following table lists constraints and types they can be used with:

Constraint	Types
alpha	string
bool	bool
datetime	System.DateTime
decimal	decimal
double	double
guid	System.Guid
long	long, ulong
int	byte, sbyte, short, ushort, int, uint, long, ulong
min(10)	byte, sbyte, short, ushort, int, uint, long, ulong
max(10)	byte, sbyte, short, ushort, int, uint, long, ulong
range(1,10)	byte, sbyte, short, ushort, int, uint, long, ulong
length(10)	string
minlength(10)	string
maxlength(10)	string
regex(\w+)	string
file	string
nonfile	string

Changes

• Added a new rule to DiagnosticDescriptors.cs:

  I used a helper method with [CallerMemberName] string name = null parameter that makes creating localizable resource strings unnecessary and simplifies creating diagnostic descriptors. Can I simplify all other descriptors this way?

• Augmented RouteHandlerAnalyzer with route constraints analysis to check if a constraint specified for route parameter is invalid for the type of the corresponding parameter declared in the route handler.

• Added unit tests.

  I used the same approach for unit tests here that I suggested separately in [Proposal] Performance/usability improvements for analyzer tests #63684

[dotnet-policy-service]

Thanks for your PR, @@Alex-Sob. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.