Port SpecFlow.Rider to Reqnroll

[gasparnagy]

The code has been forked and renamed to: https://github.com/reqnroll/Reqnroll.Rider, but never built and probably needs a few smaller fixes to make it deplyable.

@Socolin offered help, but he is quite busy this weeks, so any help from others is appretiated.

[Socolin]

I'll try to do this next next week

[ajeckmans]

I already have too much work at hand to be of any help. And seeing as I broke the last version of your plugin.. ;)
I will be able to help test the version on some real-life projects though.

[Socolin]

There is a build, if anyone can try this, https://github.com/reqnroll/Reqnroll.Rider/actions/runs/7951275864 It should still work for specflow (Except when generating steps) and it should fully work with reqnroll (But I expect small bug to adjust)

[ajeckmans]

So I finally got the chance to try it on one of our projects and I noticed two things:

1. The plugin does not work with the specflow packages. It immediately started complaining that it could not resolve any of the feature files steps to the correct bindings. After switching to reqnroll in the project it worked fine, after addressing the issues in point 2.
2. I'm not sure whether this is a regression in the rider plugin or in reqnroll.mstest, but I had to add to the project file to have rider show the .feature files as part of the project. It would otherwise only show the feature.cs files and not the feature files itself.

[FantasyTeddy]

One thing to consider in this plugin is to maybe restart or change the version number.
Since this is essentially a brand new plugin, I would not start with version 2.0, but with 1.0. Or maybe it would be worth to think about keeping the version synchronized with JetBrains versioning, e.g.: 2023.3.x (where x can be the changing number).

[Socolin]

2023.X would make sense, I did not want to lose the Changelog that why I incremented it. It's not yet published so anything can be done. I'll take a look when I have some time again.

[FantasyTeddy]

Hmmm, but the changelog would not match the actual "changes" that happened to this plugin (because they happened to the SpecFlow one). The changelog over there can still remain untouched, but I would also reset it here...

[Socolin]

One of the purpose of the changelog is to know when something happened. If someone want to work on the plugin, and figure out how something works, it might help to check when it was added to find the related commits. The version number are still present in the git history so I don't think the changelog should go away.

[gasparnagy]

@Socolin @FantasyTeddy With the main Reqnroll and the VS extension I have decided to reset the changelog, but mention at the end what version of the original plugin it is based on. (See here). I would suggest the same for the Rider plugin as well.

I would also vote for the v2024.1.x style version numbering, this is what we also use for the VS extension. (This also reduces the confusion of seeing similar version numbers with Reqnroll itself.)