Avoid setting :MetadataLanguages which affects tests using the create dataset API

[qqmyers]

As of #8437, Dataverse will support specifying the metadata language used in a a Dataset when creating/importing/migrating datasets via the API. This change will enforce rules that assure a new dataset is consistent with the requirements of the instance/parent collection where the dataset will be created. (roughly , if the :MetadataLanguages setting is not set, the dataset can't specify one and if the setting is set, the dataset must define a metadataLanguage that is in the allowed set and must also match the collection's metadatalanguage if it requires a specific one.)

Running the PR above through the build process and running the integration tests has revealed that recent ansible changes are causing the tests to run with :MetadataLanguages set to en or de-DE. (The 85 tests that create a 'random' dataset use a sample file that doesn't define a metadata language, so they fail when the setting requires en or de-DE.)

It's my understanding that the original reason for hte ansible changes (e.g. here and here were primarily intended to allow testing with the UI configured to support multiple translations. However, the inclusion of the :MetadataLanguages setting , makes the ansible default problematic.

There are several ways this could be fixed:

• The tests can be written to require the :MetadataLanguages setting to be set as it is in the ansible jenkins.yml file
• The test suite could change the setting and/or dynamically read the setting and create acceptable datasets
• The ansible languages setting can be disabled (as in this commit)
• The ansible config could be enhanced to separate the :Languages and :MetadataLanguages settings into two different options and the latter turned off by default for testing, or
• ...

This issue is to get relevant people including @pallinger , @donsizemore , @qqmyers, @scolapasta to discuss and figure out the best path forward. (The commit listed above should temporarily fix the tests to allow merging of the #8437 PR, but it doesn't have to be the long term solution.)