Clean up different usages to indicate language of content components/fragments and assets

## What are the schemas that are affected by the issue
https://github.com/adobe/xdm/blob/master/docs/reference/assets/language-alternative.schema.md
https://github.com/adobe/xdm/blob/master/docs/reference/assets/asset.schema.md
https://github.com/adobe/xdm/blob/master/docs/reference/content/componentized-page.schema.md
https://github.com/adobe/xdm/blob/master/docs/reference/content/page-component.schema.md

## What are examples of products that are impacted by the issue
Platform API for Assets

`xml:lang` is used in https://ns.adobe.com/xdm/assets/language-alternative
`xdm:language` is used in https://ns.adobe.com/xdm/content/componentized-page

But consensus may be that we use Dublin Core meta data properties should be used as in
`dc:language` as it is used in https://ns.adobe.com/xdm/assets/asset
Note that the asset schema allows dc:language to be an array of strings.

In addition, although componentized-page has a language indicator, the components (see schema `https://ns.adobe.com/xdm/content/page-component#/definitions/component` does not have a language indicator. This makes composition out of fragments quite brittle. The documentation .md file of Page Component indicates a schema hierarchy to Componentized Page, but the properties of Componentized Page are not carried into Page Component.

Start by comparing the four named schema files: language-alternative.schema.md, asset.schema.md, componentized-page.schema.md, and page-component.schema.md. Trace the existing language properties and the component definition, then document the agreed consistent language representation and ensure component fragments expose the needed language indicator. Done means the affected schemas and their documentation no longer use conflicting language conventions.

Written by the indexing model from the issue text.