Terminology changes: replacing controversial terms from our codebase

[antgamdia]

Description of the change

This (long, sorry!) PR is performing minor renames in some of the terminology used across the project.
Some automatic linters have been used to detect the issues, but in most cases, the replacement is manual (ie. please expect some unnoticed remaining items).

Perhaps we might want to add those linters as part of our Ci process; perhaps not as a blocker step (due to the false positives), but as a report we can check from time to time.
In case anyone is interested they are:

• Misspell
• vale with these style rules:
  • inclusivity (from here), Joblint, proselint, write-good

Benefits

We'll be one step ahead in the conformance with OSS good practices.

Possible drawbacks

N/A

Applicable issues

• rel Inclusive terminology - Rename master branch in Kubeapps #4075

Additional information

DO NOT MERGE

until the master branch has been renamed to main, otherwise the CI will fail.

[absoludity]

Description of the change

This (long, sorry!) PR

Personally, I have no problem with long PRs for automated or manual mechanical changes. They don't require thought. If it's not automated, but is a boring mechanical change, it just requires scanning usually. Not hard to keep context for thousands of lines :)

is performing minor renames in some of the terminology used across the project. Some automatic linters have been used to detect the issues, but in most cases, the replacement is manual (ie. please expect some unnoticed remaining items).

Right, so it's not automated, but manual mechanical changes.

Perhaps we might want to add those linters as part of our Ci process; perhaps not as a blocker step (due to the false positives), but as a report we can check from time to time.

+1 to add the linters as part of CI, assuming false positives can be noted for ignoring by the linter?

In case anyone is interested they are:

* [Misspell](https://github.com/client9/misspell/tree/master)

* [vale](https://github.com/errata-ai/vale) with these style rules:
  
  * `inclusivity` (from [here](https://github.com/vmware-tanzu/community-engagement/blob/main/INCLUSIVE_TERMINOLOGY.md)), `Joblint`, `proselint`, ` write-good`

Benefits

We'll be one step ahead in the conformance with OSS good practices.

Possible drawbacks

N/A

Applicable issues

* rel [Inclusive terminology - Rename master branch in Kubeapps #4075](https://github.com/kubeapps/kubeapps/issues/4075)

Additional information

DO NOT MERGE

until the master branch has been renamed to main, otherwise the CI will fail.

[antgamdia]

+1 to add the linters as part of CI, assuming false positives can be noted for ignoring by the linter?

It is something I'd like to work on when defining the new Kubeapps website. In fact, the linters I mentioned are from my local branch where I performed some changes for the new webpage.
But, of course, adding those linters is something we really want. Moreover, some of them already Github actions we just need to install and configure.

After the +1 from Pepe, I'm renaming master to main and merging this PR.
I'm ready to perform a follow-up/rollback PR if something goes wrong.