Fix - compare node names case insensitive

[egil]

Types of Changes

Prerequisites

Please make sure you can check the following two boxes:

• [x] I have read the CONTRIBUTING document
• [x] My code follows the code style of this project

Contribution Type

What types of changes does your code introduce? Put an x in all the boxes that apply:

• [x] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
• [ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] My change requires a change to the documentation
• [x] I have updated the documentation accordingly
• [x] I have added tests to cover my changes
• [x] All new and existing tests passed

Description

Suppose the user somehow manages to create two nodes, where one is considered unknown and thus has its node name in upper case, and the other node does not. In that case, they should still be regarded as equal, as long as their NodeType are identical and NodeName is the same (case insensitive).

Inspired by the question here: https://stackoverflow.com/questions/75335821/bunit-simple-markup-verification-for-path-tag

A simple example is this:

Let the control node be the <path> element found by parsing <svg><path></path></svg> and select the first child. Let the test node be the result of parsing <path/>. This will result in an IUnknownHtmlElement being returned.

Then the element comparer should consider the control node and the test node equal.

Ps. PR also includes some housekeeping commits.

[egil]

Ps. I have completely forgotten how we update the changelog. Please advice and ill push an update.

[egil]

In general looks good.

Regarding the question: Just edit CHANGELOG.md (https://github.com/AngleSharp/AngleSharp.Diffing/blob/devel/CHANGELOG.md). I see that There is a preview of 0.18 out. I'd suggest to make this 0.17.1 instead to keep parity with the used AngleSharp libraries.

I noticed that too. Not sure how that version number came to be though. Does our build script support making this 17.0.1 and pushing that out now that 1.8 is out?

I do not see a reason not to include the changes in 1.8 as well as these changes together, and just making 1.8 not be in preview anymore, so we could do something like that.

It would be nice to keep diffings version aligned with anglesharp, but hopefully they can all be bumped to 1.0.x soon, anyway, so I would rather just push a new none-preview that includes all the changes we have in the pipeline.

[FlorianRappl]

I do not see a reason not to include the changes in 1.8 as well as these changes together, and just making 1.8 not be in preview anymore, so we could do something like that.

You can just unpublish 0.18.x preview. Really these are just previews - so no worries here.

[egil]

I do not see a reason not to include the changes in 1.8 as well as these changes together, and just making 1.8 not be in preview anymore, so we could do something like that.

You can just unpublish 0.18.x preview. Really these are just previews - so no worries here.

as in go to nuget.org and click hide them?

[FlorianRappl]

as in go to nuget.org and click hide them?

Yeah I think that's what I did at least with some (really old) 1.0.0 preview packages of AngleSharp itself.