The validate-modules sanity test now also validates plugins

[felixfontein]

Today ansible/ansible#71734 was merged to ansible-core's devel branch, which extends ansible-test's validate-modules sanity test to also validate the documentation (and thus configuration) for (documentable) plugins.

You might notice some CI failures related to this. Please note that some choices in the schema are opinionated, but I didn't make them up (all by) myself :) Some of these were discussed and settled by the core team in some issues (ansible/ansible#71792, ansible/ansible#71793, ansible/ansible#71794, ansible/ansible#71795, ansible/ansible#71796, ansible/ansible#71797, ansible/ansible#71798).

If you encounter a situation where you think something is wrong, feel free to mention that in the discussion: #11

[felixfontein]

Today an extension to validate-modules was merged (ansible/ansible#77268) that does some more checks for plugins, but also affects module validations. It affects only DOCUMENTATION, and thus also works for plugins:

1. required: true and a present documentation default: raises an error (similar to when this is done in a module argspec);
2. elements present without type=list raises an error (similar to when this is done in a module argspec);
3. elements not present with type=list raises an error (similar to when this is done in a module argspec);
4. the types of choices and default are checked if the type is a valid type for a plugin.

For modules, 4. can result in new errors. The most common is when using an integer as a choice or default value for type=str. (For choices this is a serious problem for plugins, as no conversion is done on choices elements. For default and for modules this is different.) While this isn't fully necessary, it makes rendering the proper type of a value easier (for everything that wants to render documentation) since this makes sure that the YAML type uses actually equals the documented type.