[Ada] Implement AI12-0249, AI12-0295 (user-defined numeric & string literals)

[Ada] Implement AI12-0249, AI12-0295 (user-defined numeric & string literals)

2020-06-16  Steve Baird  <baird@adacore.com>

gcc/ada/

	* snames.ads-tmpl: Define names of the three new aspects.
	* aspects.ads: Define the three new aspects.
	* sem_util.ads, sem_util.adb, sem_dim.adb: Move the function
	String_From_Numeric_Literal from being declared in the body of
	package Sem_Dim to being declared in the visible part of package
	Sem_Util.
	* sem_ch13.ads, sem_ch13.adb: Declare new visible procedure
	Validate_Literal_Aspect. This is where most of the legality
	checking occurs for an aspect specification for one of the three
	new aspects, as well as resolution of the subprogram named in
	the aspect specification. Follow example of other aspects (e.g.,
	Validate_Literal_Aspect is called in much the same way as
	Validate_Iterable_Aspect in Analyze_Aspects_At_Freeze_Point; a
	small amount of legality checking is performed in
	Analyze_One_Aspect in much the same way as for Default_Value or
	Default_Component_Value aspects). Most of the work is done in
	Validate_Literal_Aspect.
	* contracts.adb (Add_Contract_Item): Call
	Validate_Literal_Aspect in much the same way that
	Validate_Iterable_Aspect was already being called.
	* sem_res.adb (Resolve): Rewrite a literal as a call if it is a
	user-defined literal.  This is where the dynamic semantics of
	the 3 new aspects are implemented.
	* sem_ch6.adb (Fully_Conformant_Expressions): Two numeric
	literals that have different text but the same value (e.g.,
	12345 and 12_345) do not conform if they are user-defined
	literals. Introduce a new function
	User_Defined_Numeric_Literal_Mismatch to avoid duplication in
	making this check.
	* sem_type.adb (Has_Compatible_Type): A numeric literal can be
	compatible with a non-numeric type (and a string literal can be
	compatible with a non-string type) if it can be interpreted as a
	user-defined literal.