prefer adding_software over contributing_sw in docs URL + fix broken URLs using auto-redirect

[boegel]

Summary of changes:

• rename docs/contributing_sw/* to docs/adding_software/*: no need for using cryptic things like 'sw' to shorten URLs, and we consistently use "adding software" throughout this part of the docs;
• fix broken URL https://www.eessi.io/docs/adding_software by auto-redirecting to https://www.eessi.io/docs/adding_software/overview;
• fix broken URL https://www.eessi.io/docs/software_layer/adding_software by auto-redirecting to https://www.eessi.io/docs/adding_software/overview;
• add links to subsections in /adding_software/overview page rather than leaving a TODO there;
• move reference to target audience (contributors or maintainers) out of page title to clean up docs menu

[casparvl]

Two general comments.

We had a prior discussion on whether to use 'adding' or 'contributing'. I used contributing because it makes clear that it is something anyone can do. You also use 'contributing to EasyBuild' in the EasyBuild docs when you talk about EasyConfigs that people contribute. A page on 'adding software' to me creates less clear expectations to the reader - it could also just describe how we add software, or how software gets added by others. Hence my preference for 'contributing': it really makes clear someone can do it themselves. Note that Thomas also brought up 'adding' as an alternative, see her #117 (comment)

If both of you really feel that 'adding' is better, I'm ok in changing it.

Regarding the redirect links: I'm completely fine with giving it a try, but in one of the meetings (support meeting? Can't remember, maybe it was just private conversation with Thomas) we also concluded that keeping all links indefinitely active would be a nightmare. I don't think anyone will be too 'lost' that they can't figure out to go to the root of the page and start their search from there.

Especially since we are a project in its early phase, I imagine the docs might change quite a bit a few more times. Having to create redirects for all of those might make that mkdocs.yml a bit messy.

Anyway, I'm not against it, so let's keep it in this PR. Regarding the 'contributing' vs 'adding' discussion: please give it another thought which of the two headersyou think helps people to find the right page for what they want to do. If you still feel that's 'adding', I'm ok with that too. In that case: feel free to even merge this PR yourself - apart from making sure you give it another thought, I have no further objections :)

[boegel]

@casparvl W.r.t. redirects: that's basically "do once and forget" in mkdocs.yml, so I'm very much in favor to never have any broken URLs in the EESSI docs. People may have EESSI docs URLs in bookmarks, emails, Slack, GitHub issues, etc., and they should never run into a 404 page if the visit a link that worked before. It should either be an automatic re-direct (like I'm doing here), or a page that tells you that docs have been moved (see http://www.eessi.io/docs/software_testing).

Being a project under heavy development is not a good excuse for broken URLs in docs imho, since we're literally talking about adding a single line in a YAML file per changed URL whenever we change our mind w.r.t. structure of the documentation (which is fine, docs should evolve over time). Not wanting to do make that small effort and let people hunt for the info they're looking for in the restructured docs is a bit lame imho (I certainly get very annoyed personally when I hit a 404 page for a URL that I know used to work).
Go check the list of redirects we do in the EasyBuild docs (see here). There's no maintenance burden there, at all, we rarely touch that list (we basically only did when we moved away from ReadTheDocs).

There's also no real negative side to keep a (long) list of redirecting URLs, other than perhaps a longer mkdocs.yml.

W.r.t. adding vs contributing: I guess you could argue both ways. It's more about consistency for me: the current URL uses contributing, while the pages itself still use "adding" (see http://www.eessi.io/docs/contributing_sw/opening_pr/). The actual trigger was the sw part though, I see absolutely no reason to use sw rather than software.
Using adding in the URL is the easiest change to keep things consistent, imho.

That said, I prefer "adding" over "contributing". Mostly because it's easier to understand (and contributing sounds like more work perhaps for someone new to the concept of EESSI).
You're not really "contributing" software to EESSI in the sense that I usually understand it: the software already exists (it was created by someone else). In the context of EasyBuild, I feel it's different: there you are contributing the support to install particular software packages.
In EESSI, you're proposing to add software to EESSI as a contributor, by opening a tiny PR that updates the definition of the software stack (an easystack file). That last specific action is a contribution imho (see item 1 here), but that's only part of the process for adding software to EESSI: it also involves building the software, actually deploying the installations in the repo, etc.

[casparvl]

Ok, fair enough, happy with @boegel 's reply. Merging!