Run jscpd against the workspace

[ferrarimarco]

Proposed Changes

• Run jscpd, gitleaks (not anymore, see Build the file list and run linters in parallel #5177), textlint (not anymore see Enable linting changed files with textlint #5100) against the entire workspace instead of
  running them over single files, one by one.
• Implement a warning function for deprecated variables.
• Deprecate the VALIDATE_JSCPD_ALL_CODEBASE variable.
• Deprecate the EXPERIMENTAL_BATCH_WORKER variable, and related code, so we can implement a more scalable approach.
• Remove duplicate configuration files from .github/linters when they are the same as the ones we ship in TEMPLATES.
• Add a missing bad tests for ansible-lint.
• Move ANSIBLE_DIRECTORY configuration when running tests in
  buildFileList, where similar configs are.
• Simplify ansible-lint test cases to include only what's necessary, and
  not an entire set of roles, playbooks, and inventory.
• Fix jscpd looks for code duplicate in images #3966

Readiness Checklist

In order to have this pull request merged, complete the following tasks.

Pull request author tasks

• I included all the needed documentation for this change.
• I provided the necessary tests.
• I squashed all the commits into a single commit.
• I followed the Conventional Commit v1.0.0 spec.

Super-linter maintainer tasks

• Label as breaking if this change breaks compatibility with the previous released version.
• Label as either: automation, bug, documentation, enhancement, infrastructure.

[ferrarimarco]

(more context, originally posted in #4852 (comment))

This PR makes the following linters run against the entire workspace in one go, instead of linting file by file:

• jscpd, because looking for duplicates in files processing them one by one doesn't consider duplicates in other files, to it makes this linter way less effective, and it costs a lot in terms of overall performance.
• textlint, because it's based on plugins, and each plugin handles certain types of files. Also, textlint lets users specify custom extensions for a given file type in addition to the defaults. So, we let textlint handle this, instead of reimplementing the same logic. For example, with default plugins, textlint can lint txt and md files only, so there's no point in running it against all files one by one. If we/users install another textlint plugin, we don't need to modify any logic to handle an additional extension, nor custom extensions for any given plugin that users might have configured.
• Gitleaks, because we want to scan the whole workspace anyway.

This approach also has the added benefit of letting users rely on the file listing and ignoring logic of each linter, so their configuration becomes more portable if they decide to run the same linter by other means.