Sorted the list of plugins to enable deterministic loading of plugins

[MWild67]

🤔 What's changed?

During plugin discovery the list of found plugins is sorted to enable deterministic loading of plugins

⚡️ What's your motivation?

As described in Ideas #502 the problem is that the plugins are discovered by querying files in directories. This behavior is different depending on the underlying filesystem, means:
Window/NFTS: alphanumerical
Linux/ext: "inode" order

This leads to the situation that the loading is different when you locally test with Windows and on the pipeline the tests are running on a linux agent.

This is per se a bit inconsistent, but for us it is a problem as we have a plugin which is overwriting the tracing. We enforce by the plugin-name that our plugin is loaded last, which now only works with NTFS.

🏷️ What kind of change is this?

The list of plugins which is given back is sorted alphabetical

♻️ Anything particular you want feedback on?

📋 Checklist:

• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• Users should know about my change
  • I have added an entry to the "[vNext]" section of the CHANGELOG, linking to this pull request & included my GitHub handle to the release contributors list.

---

This text was originally taken from the template of the Cucumber project, then edited by hand. You can modify the template here.

[gasparnagy]

Looking at the implementation of RuntimePluginLocationMerger it seems that the (same) plugins might be stored at different paths and the merger is removing the duplicates based on the file name (ignoring the folder).
Based on that, it would be probably more consistent if the ordering would also be done just based on the file name and not the full path. Maybe this ordering should be moved to RuntimePluginLocationMerger...