Endianness sometimes is a beast

[invertedtomato]

          Endianness sometimes is a beast, the "TODO" in your code isn't for nothing:

I have created https://dotnetfiddle.net/OYNy6O that uses https://learn.microsoft.com/en-us/dotnet/api/system.io.hashing.crc32. https://crccalc.com/?crc=123456789&method=CRC-32&datatype=ascii&outtype=0 results in CRC of 0xCBF43926. The fiddle results in the same.

Now, crc.GetCurrentHash() "emits the answer in the Little Endian byte order", e.g. the LSB [0] is 0x26. This sequence is the reversed of the result of your CrcAlgorithm.ToByteArray(), which is:

It took me quite a while to conclude on this. The method's summary "...the CRC of the bytes that..." doesn't help much. While it is OK to have CrcAlgorithm.ToByteArray() reverse to big-endian, I think this must be improved, as other users likely fall into the same pit. Ideas:

• Leave ToByteArray() as is, but better comment its behavior.
• Add new methods following the NonCryptographicHashAlgorithm like [GetCurrentHash](https://learn.microsoft.com/en-us/dotnet/api/system.io.hashing.noncryptographichashalgorithm.getcurrenthash?view=dotnet-plat-ext-7.0#system-io-hashing-noncryptographichashalgorithm-getcurrenthash), with equal semantic.
• Deprecate ToByteArray().

Originally posted by @maettu-this in #9 (comment)

[invertedtomato]

@maettu-this , I'm open to this, however won't have time to implement myself. If you were to PR this I'd be happy to include it