Install `yamllint` and the Python libraries used for code linting and formatting for developers

[jsf9k]

🗣 Description

This pull request installs yamllint and the Python libraries we use for code linting and formatting.

💭 Motivation and context

We can expect developers to install non-Python tools locally via their system's package manager, but the Python-based tools are a different case. We provide requirements*.txt files to encourage developers to set up a local Python virtual environment (venv), and many editors will make use of that venv when performing syntax checking and the like. It therefore makes sense to go ahead and include in requirements-dev.txt any Python tools that we use for formatting and linting of code.

• Including yamllint is useful because there are a lot of YML files in an Ansible role. Including yamllint in the virtual environment for developers will allow their editors to syntax-check these files.
• Including the Python code linting and formatting tools is useful because our Molecule test suites are all written in Python. Including these tools in the virtual environment for developers will allow their editors to automatically lint and format code. It also allows developers to run the tools manually if they wish to do so.

(Note that installing mypy would be even more useful if pytest-testinfra were typed, but that is not yet the case. See pytest-dev/pytest-testinfra#619 for more details about that.)

I noticed that my editor was complaining about trying to use mypy to provide more information but not finding it available, and I verified that installing it in my venv made that complaint go away. That's what started this whole PR effort.

🧪 Testing

All automated tests pass. I noticed that my editor was complaining about trying to use mypy and yamllint to provide more information but not finding them available, and I verified that installing them in my venv made the complaints go away.

✅ Pre-approval checklist

• [x] This PR has an informative and human-readable title.
• [x] Changes are limited to a single goal - eschew scope creep!
• [x] All relevant type-of-change labels have been added.
• [x] I have read the CONTRIBUTING document.
• [x] These code changes follow cisagov code standards.
• [x] All new and existing tests pass.

[jsf9k]

Now that I've created this PR, I think that cisagov/skeleton-generic might be a better home for these changes. What do you think @cisagov/vm-dev?

[jsf9k]

I don't really understand the heavy overlap with our pre-commit configuration here. All of these tools (exceptingmypy) can just as effectively be run using pre-commit run --all-files, more specifically pre-commit run <hook name> --all-files, or with pre-commit installed as a git hook it will be run on commit. mypy is a separate case because of how it interacts when living in a Python venv, but everything else would potentially conflict with our pre-commit configuration since there is no version pinning happening here.

You raise a good point. In the interest of documenting the intent behind this PR, these are the types of problems I was trying to solve:

1. I'm editing a Python file and my editor wants to provide extra typing information, but it can't because mypy isn't installed in the local venv (which my editor is using).
2. I'm editing a Python file and my editor wants to provide flake8 warning and error information, but it can't because flake8 isn't installed in the local venv (which my editor is using).
3. I'm editing a YML file and my editor wants to do some syntax checking with yamllint, but it can't because yamllint isn't installed in the local venv (which my editor is using).
4. I'm editing a Python file and I know that black will want to make changes. To save time I'd like to go ahead and run black against the file without leaving my editor. I can't do that because black isn't installed in the local venv (which my editor is using).

I will handle these dependencies locally. I thought this addition might be useful for others, but I can see that it would cause headaches.