Improve versions parsing and displaying

[tleb]

We have quite a few issues related to versions currently. This is an issue to centralise discussion on the topic.

• Projects must have a three level deep structure for versions. It doesn't fit all projects, eg oFono has a single entry inside each submenu. OPTee has two/three entries in each menu; the display would be simpler if we removed the submenu. Toyboy doesn't need its menu separation as there is only a v0. uclibc-ng only has v1.0.X versions.
• Some projects list versions as v1, others as 1.
• Some projects have an old menu. Why? DPDK has v16 thru v25 then in its old menu, has v1.2 to v2.2.
• Some versions have their names coming from Git tags (I guess) and are not formatted in a standard way. eg grub-2.12.
• glibc has all its versions and a duplicate tag with suffix -9000. Eg glibc-2.41 and glibc-2.41-9000.
• glibc has a fedora menu with some versions, eg fedora/glibc-2.12.90-6. Those should probably appear in the correct submenu alongside the upstream version, not in a separate menu.
• U-Boot has an old menu with by-date and by-version.
• This isn't a weird behavior like the above, more of a feature request. We should easily be able to find where a tag comes from, eg the glibc fedora tags. For that, projects should emit an URL for each version, that would be inserted inside the footer (the tag name is already there).

Overall, we should simplify the handling of versions. It appears all projects use some sort of semver-ish format. Projects should be responsible for emitting a list of versions in that format. From that, we check everything corresponds to the format and we build the version tree ourselves (making decisions like picking the depth and grouping or not minors together).

Downstream tags (eg glibc fedora) would be the ones where we cheat the most, turning them into v2.12.90-6-fedora for example.

The approach has one big benefit: if the project-specific code ever breaks, we would be alerted as its output wouldn't be semver formatted. Currently there is no barrier in place.

Currently most projects must generate their own tree by implementing a custom list_tags_h(), which is way too error-prone.