doc: add glossaries for contrib and dev

[atmaxinger]

Basics

• Short descriptions of your changes are in the release notes
  (added as entry in doc/news/_preparation_next_release.md which
  contains _(my name)_)
  Please always add something to the release notes.
• Details of what you changed are in commit messages
  (first line should have module: short statement syntax)
• References to issues, e.g. close #X, are in the commit messages.
• The buildservers are happy. If not, fix in this order:
  • add a line in doc/news/_preparation_next_release.md
  • reformat the code with scripts/dev/reformat-all
  • make all unit tests pass
  • fix all memleaks
• The PR is rebased with current master.

Checklist

• I added unit tests for my code
• I fully described what my PR does in the documentation
  (not in the PR description)
• I fixed all affected documentation (see Documentation Guidelines)
• I fixed all affected decisions (see Decision Process)
• I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
• I updated all meta data (e.g. README.md of plugins and METADATA.ini)
• I mentioned every code not directly written by me in reuse syntax

Review

• Documentation is introductory, concise, good to read and describes everything what the PR does
• Examples are well chosen and understandable
• Code is conforming to our Coding Guidelines
• APIs are conforming to our Design Guidelines
• Code is consistent to our Design Decisions

Labels

• Add the "work in progress" label if you do not want the PR to be reviewed yet.
• Add the "ready to merge" label if the basics are fulfilled and no further pushes are planned by you.

[atmaxinger]

The aim of this PR is to add two new glossaries, one for dev and one for contrib. I'm not planning on adding much in there in this PR. I will rebase my open decision PRs once this is merged and add stuff to the glossary in those PRs

[atmaxinger]

Feel free, however, to suggest stuff I can put in there before merging.

[markus2330]

I think both Hooks and Change Tracking are terms even end users will be confronted with. So doc/help/elektra-glossary.md should be fine for these terms. Change Tracking is a feature for admins after all, not for devs or contributors.

Most of the technical concepts in doc/help/elektra-glossary.md, however, probably should be moved to dev/.

There were other terms that were used in the UI descriptions, which are not present here. As it is quite some time ago, I don't remember them anymore. One was session but this term in specific should be irrelevant now?

[atmaxinger]

Change Tracking is a feature for admins after all, not for devs or contributors.

Well, Change Tracking is something internal to libelektra-kdb. What you are referring to is recording. Recording builds on change tracking but has to do quite a few more things.

Most of the technical concepts in doc/help/elektra-glossary.md, however, probably should be moved to dev/.

Agree, but should I move the linked files also? That would mean that we lose manpages for those concepts.

There were other terms that were used in the UI descriptions, which are not present here. As it is quite some time ago, I don't remember them anymore. One was session but this term in specific should be irrelevant now?

I'd much rather add those terms in the appropriate PRs.

[kodebach]

@atmaxinger There is a manpage version of the glossary, so you need to run make man before pushing so the manpage gets built.

[kodebach]

LGTM

[markus2330]

@atmaxinger maybe this for release, too?