Enable C# 8's nullable annotations

After #228 is merged, we should be able to enable the new nullable reference types all over our project. It’s important so we could provide the nullability information through our API for the users.

Remaining points to do:

• fix this: https://github.com/ForNeVeR/wpf-math/blob/c8c6a5f4efc88ddbc0f6807693c7f09906470e20/src/WpfMath/Atoms/RowAtom.cs#L62
• BigOperatorAtom.BaseAtom should become non-nullable
• ScriptsAtom.BaseAtom should become non-nullable
• make StyledAtom’s constructor parameter atom non-nullable, add asserts
• make TypedAtom.Atom non-nullable, add asserts
• make UnderlinedAtom.Atom non-nullable
• make VerticalCenteredAtom.Atom non-nullable
• make OverUnderBox.ScriptBox non-nullable
• PredefinedFormulaParser shouldn’t return null? to fix predefinedFormula!.RootAtom! (TexFormulaParser.cs:648)
• make Radical.BaseAtom non-nullable
• remove TODO / fix the issue with RowAtom ctor (see RowAtom(SourceSpan? source, IEnumerable<Atom?> elements))
• fix an issue with RowAtom(SourceSpan? source, Atom? baseAtom) (see the comment there)
• review any remaining comments about // Nullable TODO and remove TODO or fix them
• review any remaining comments about // Nullable

[ForNeVeR]

I’ve decided to keep this issue open even after merging #277. Remaining small pieces of work are enumerated in the opening post.

[ygra]

Ok, I’ve stashed the mishmash of fixes I’ve had to far (down to 47 warnings) and decided to start anew with a gradual approach (I can still pick changes from the stash to avoid duplicating work). This makes it easier to commit piecemeal enablings and fixes as well as making it easier to track what nullability inclusion now brought nullable types all over everything (there were a few very viral parts that could perhaps better be tackled at the source to not let them be null to begin with).

I’ll probably issue the first partial PR today or tomorrow, since I’m offline for a week after that and building a WPF library on my Linux laptop won’t work so great.

One thing I noticed is that with TargetFramework=net452 the analyzer seems less smart and ignores things like Debug.Assert and other things. This made a few ! necessary. I’ve commented all of them for now and if someone has a better idea to solve a particular instance we can fix them in another way (! is just the quickest fix to silence the diagnostic, of course 😉).