Fix "Pad*" signatures with more honest nullable annotations

[atifaziz]

This PR adds to #803. Where a TSource is defaulted for padding, the signature now clearly says TSource?.

[viceroypenguin]

Idle curiosity on NRT handling: I wonder if passing a Func<int, T> will return an IEnumerable<T> or IEnumerable<T?>. Looks good regardless

[atifaziz]

Idle curiosity on NRT handling: I wonder if passing a Func<int, T> will return an IEnumerable<T> or IEnumerable<T?>.

Will return based on whatever T is for the instantiation.

Looks good regardless

Almost. Had one of the overloads wrong but hopefully fixed with 58ca7f9.

[viceroypenguin]

Without the Defaultable<T>, it complains? Is it better to add the Defaultable<T> or to just ! it away? Seems like a lot of work to avoid a single character.

[atifaziz]

Without the Defaultable<T>, it complains?

Yes.

Is it better to add the Defaultable<T> or to just ! it away?

I'll admit I'm being sneaky with the compiler, but I am toying with the idea and wanted to throw it here to get reactions from reviewers so thank you for yours!

Seems like a lot of work to avoid a single character.

JIT should optimise Defaultable<T> away 100% so it should have zero runtime impact. Putting that technical detail aside, my goal here was not to save on the single character, but:

1. not having to default! at all every call site (usually less important).
2. making it obvious in the (always private) method signature that the argument may be defaulted due to mutual exclusion with some other argument.
3. quickly find all references of Defaultable<T> at some point in the future for code analysis.

While it might seem extreme for Pad, I am hoping it will help in other cases like FallbackIfEmpty. If it ends up being a bad or an over-the-top idea then one can find all references (3) and revert.

[viceroypenguin]

I'm good w/ the explicit Defaultable<T>. Definitely agree that it will JIT away, was more on the "why create it" aspect. If it works, then 🤷‍♂️