Types removal - PUT and GET IndexTemplates.

[markharwood]

Add support for the include_type_name flag.
For HLRC support PutIndexTemplateRequest now includes checks to change the toXContent format if it looks like custom doc types are used in mappings.

[elasticmachine]

Pinging @elastic/es-core-features

[markharwood]

jenkins test this

[markharwood]

I've refactored PutIndexTemplateRequest as part of this PR so that we can expose it safely in HLRC.

Internally the mappings Map contains JSON strings keyed on the doc type.
These JSON strings are supposed to be of the form "mappings":{ "my_doc_type": { "properties":... and a method internalMapping is used to insert the choice of doc type into the string if it is missing from the provided content (it is assumed clients can omit this). I've kept this approach.
However, PITR has many public methods with different ways of passing mapping blobs (XContent, maps, byte arrays etc) and not all of these ran the provided content past the internalMappings storage function - some injected typeless content strings, untreated straight into the mappings map which violates the assumption that these internal mapping strings are always typed.

This was the set of inconsistent approaches used:

method	param type	upgrades mappings to internal typed format
mapping	BytesReference	N
mapping	Map<String, Object>	Y
mapping	XContentBuilder	N
mapping	Object... source	N
source	BytesReference	Y
source	byte[]	Y
source	XContentBuilder	Y
source	Object... source	Y
source	Map<String, Object>	Y

Several of these methods call each other internally. I refactored them so that they all ultimately call internalMappings to ensure a type is injected where missing as that is the internal storage format.
When we use PITR in HLRC and render to XContent we strip the type name if it is the default of "_doc".
Other parts of PITR assumed the type names were in the mapping content when parsing and I have deprecated these (methods called mapping or source) and introduced alternative sourceNoDocTypes and mappingNoDocTypes equivalents that assume there's no type name in the mapping content provided. These are used in the HLRC examples.
This may seem odd but the need for this is that while it is possible for internalMapping to detect typeless content and "upgrade" to typed it is not possible for source(Map<String, Object> templateSource) to detect already typed content (legal choices of doc type name can clash with mapping fields like properties). This method is delegated to a lot internally. Sadly, HLRC clients need to be explicit about whether the content is typed or untyped by the choice of method name they invoke.

[markharwood]

jenkins test this

[markharwood]

The outstanding work required here is that:

1. We need an equivalent of Add an include_type_name option to 6.x. (#29453) #37147 to add 6.x support for include_type_name with index templates.
2. Once 1) is committed I need to switch this PR's default to include_type_name=false (preferably referring to a constant for this policy recommended as part of Update the default for include_type_name to false. #37285 (comment)). This PR will then need a bunch of existing yaml test changes similar to those in Update the default for include_type_name to false. #37285 which makes these tests 6.x and 7.0 compatible by adding include_type_name=true to tests that use typed templates

[markharwood]

This overlaps with #37210 so not doing any more on this