Rationalize pylint in build workflow

[bbassett-tibco]

Right now, the main build workflow under the "Actions" tab will blindly install the latest version of pylint. This can cause problems when our repository has been quiet for a while, and we make a commit after a pylint release that has introduced a new check that finds a problem in our code. The new commit then fails because the new checks find that new problem, but the new commit isn't technically at fault.

To fix this, we should do one of the following:

• Fix the version of pylint that is installed by the workflow, so that we don't have the unscheduled introduction of new checks. We would then need to manually revise this fixed version as newer versions of pylint are released (along with changes to our code to fix new checks).
• Add automation to periodically run the then-current version of pylint, and indicate to the project (probably through filing a GH issue) that there are failed checks. (In this case, we should be cognizant not to file multiple issues about new failures in new checks, probably through some sort of mechanism that requires us to rearm the filing of issues when committing changes to remedy new pylint checks.)

[bbassett-tibco]

The version of pylint used by the main build workflow has now been fixed (and is specified in the requirements_lint.txt file). Additionally, a new workflow is set to run every Monday morning Pacific time that will run the latest version of pylint and file an issue if new issues crop up (and will not even run if an existing issue is still open in order to limit the potential to file duplicates).