Restructuring fmf documentation

[LecrisUT]

Continuing from #264 (comment).

In hope of expanding fmf beyond tmt context, I am proposing some restructuring of the documentation section to be more generic and easier to follow as a passer-by (what is this fmf thing about), basic-user (how do I write my first fmf tree), power-user (what's new in fmf, where's the reference guide), external developer (how do I work with fmf as a library), internal developer (python api, contribution guide).

One restructuring I am thinking of is having the following pages:

• "What is fmf": a simple explanation of fmf as yaml + file structure with inheritance.
• "Features": all the capabilities and definitions of fmf
• "Advanced designs": suggestions for how to structure the fmf tree, advanced in-tree control parameters like /.inherit, advanced tree control parameters in .fmf/config, full list of operators (just because can't find a better place)
• "Developer corner": what to expect from .fmf/version, how to expand fmf and more such topics

The concept page is too tmt specific and it's hard to parse outside of it. I think most of the content could be converted to a "what/why fmf".

[LecrisUT]

Extracted from comment with @psss: Rename Module to something more standard, Code/API Reference/Python (API) Reference