Init setup to lint HTML & HTML ERB files

[Splines]

New HTML Linters

~~With version 2.1.0, I've made my eslint-plugin-erb ready to be pluggable into html-eslint, also see my comment on this issue. This allows us to lint the pure HTML part (in .html and .html.erb files).~~

HTML ESLint now comes with the option to integrate templating engines such as ERB into it. With this PR, we configure our ESLint setup to include the respective HTML parser such that we can also lint HTML files (excluding the ERB tags in HTML files).

To also lint the ERB tags inside .html.erb files, I set up Shopify's erb_lint and deactivate purely HTML-specific linters in it (since for that we have HTML-ESLint). This allows us to have RuboCop look over the ERB tags and integrates many other Ruby-related linters, which is quite nice.

With this approach we hopefully get the best of both worlds: purely HTML linting and linting of Ruby code embedded as ERB tags in our HTML files.

---

VSCode Integration

• ESLint is already included in our setup as VSCode extension, such that you will now also get support for any HTML files. I've added respective rules for this.

[!tip] After having checked out this branch, you have to update your NPM dependencies, i.e. yarn install. Otherwise, no linting with ESLint will work anymore.

• erb_lint only offers a CLI tool. I've also tried out this ERB Linter extension but it didn't quite work for me. So, instead, I've added this Run on Save extension and let it run the erb_lint CLI every time the file is saved. I've also added the respective CLI command to a new just lint erb command.
  Note that compared to the speed of ESLint wrapped inside the extension, this is really slow as bundle exec has to be invoked and then erb_lint itself seems to be quite slow. So what you will experience is quick linting for pure HTML, then wait (quite) a bit to also get ERB parts auto-corrected.
  In the future, we might consider finding (or writing our own small) VSCode extension such that erb_lint can run more quickly on files as it doesn't have to use the terminal and instead can be directly integrated as formatter into the VSCode API.

[!tip] I've added a new recommended extension (Run on Save) to our workspace that you should install in order for erb_lint to work automatically as soon as you save the file.

[!warning] erb_lint will overwrite the file content. As it is slow, you might have already adjusted the file in the meantime. VSCode will then show a popup "The content on disk is newer...". As this is quite annoying, I've added the "files.saveConflictResolution": "overwriteFileOnDisk",. This also means: don't edit files outside of VSCode for MaMpf, otherwise you might loose some code!

---

Reviewers

• See the available HTML linting rules here. I've not included all of them and only those that I think might make sense for our codebase.
• Please experiment with the results you get based on the two new linters. That is, open any .html or .html.erb file, add a space and then save the file such that the linters autocorrect it.

After this PR, I will file another PR that does something like this:

yarn run eslint --config ./.config/eslint.mjs --max-warnings 0

and additionally adds the --fix option.

I also hope that html-eslint will get a max-length for lines, see my feature request here: https://github.com/yeonjuan/html-eslint/issues/251.

[Splines]

@MaMpf-HD/core Hey there, I've reworked this PR and we now don't use my custom preprocessor anymore for HTML, but instead the template engine integration that found its way into html-eslint in the meantime.

Please make sure to test out the linting rules on real-world examples as I will file another PR afterwards that autocorrects the entire codebase with these rules (maybe this would be something for after the vignette PR and even after the Ruby and Rails upgrades).

[fosterfarrell9]

I just played around with it a little. Works very nice (mostly). Among the files I tested, there was one that had a rather strange formatting afterwards: app/views/administration/classification.html.erb. Can you check if that happens for you as well? Also, I wondered why the form helper methods like f.text_field etc all get extra parentheses added while something like link_to does not (see e.g. app/views/referrals/_form.html.erb) and stays as it is.

[Splines]

Closed due to #935