Rework SpanByte

[networkfusion]

Description

• Fix comments for Intellisense.
• Fix constructor returning null in certain execution paths.
• Remove verbose messages from exception constructors.

Motivation and Context

How Has This Been Tested?

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (add new Unit Test(s) or improved existing one(s), has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).
• I have added new tests to cover my changes.

[networkfusion]

SonarCloud is still not happy, but then again, this is not UserCode!

For Reference: https://rules.sonarsource.com/csharp/RSPEC-112

Perhaps we should consider suppressing those? https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/suppress-warnings

[josesimoes]

SonarCloud is still not happy, but then again, this is not UserCode!

For Reference: https://rules.sonarsource.com/csharp/RSPEC-112

Perhaps we should consider suppressing those? https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/suppress-warnings

These can't be turned off because that's not always the case. These warnings are suppressed individually either in the code, by wrapping the "offending" code with a suppress warning compiler def or directly in sonarcloud analysis by marking the issue with "won't fix". The 1st one is the preferred one as it shows and documents the intented usage.

[josesimoes]

Looking at the code, there are other places begging for improvements, like the verbose exception messages.

Also I'm not fully convinced about some checks on the constructor.

[josesimoes]

I don't think that the check on line 57 is correct. It should be: (start >= array.Length))

[Ellerbach]

Looks good to me