feat: Make adding new versions easier

[HagerDakroury]

Checklist

• I indicated which issue (if any) is closed with this PR using closing keywords
• I only changed lines related to my PR (no bulk reformatting)
• I indicated the source and check the license if I re-use code, or I did not re-use code
• I made my best to solve only one issue in this PR, or explain why multi had to be solved at once.

Details

During a discussion with @matuskalas last week, we agreed that it'll be for the best if we tried to put all hard-coded values related to the versions (links, the order in dropdown menu, labels, etc.) in one file.

The goal behind that is to have the possibility of adding a new version and updating existing ones (like "stable" to 1.26 instead of 1.25) be as seamless as possible, with just one or 2 lines change.

This PR achieves that.
To test/add a new version:

1. Add the version key as a property in this map (with any order), with the appropriate label and url (if not found, it will be loaded from the base url)
2. Add the key to this array with the desired order in the dropdown menu.

That's it! Example of adding 1.22:

[matuskalas]

Awesome, thank you so much @HagerDakroury 🙏🏽 This will indeed make a very big difference for ontology maintainers🙌🏽

One last thing before merge: @HagerDakroury, would you please rename the file to anything you agreed on with @bryan-brancotte, such as 'ontoBrowserConfig.js' or 'configOntoBrowser.js' or similar, shorter/longer... Million thanks! 🙏🏽🙇🏽‍♂️
(because if we renamed it later, the history might not be properly visible on GitHub)

[matuskalas]

❤

[HagerDakroury]

@bryan-brancotte has suggested moving this part to the config file as well, as its edam-specific