Retroactive compiler bugfix allowing null conditionals to evaluate to pointer types

Since no language in the specification specifically prevents `a?.B` when `B` has a pointer type, the language design team has decided to enable this syntax for all language versions (back to 6) and consider it a compiler bugfix. It is not a breaking change.

Would we like to do anything in the spec to clarify one way or the other?

LDM notes ():

> ### Null-conditionals evaluating to a pointer type
>
> Issue: https://github.com/dotnet/roslyn/issues/7502
> Spec: https://github.com/dotnet/csharpstandard/blob/41694caebb0fb759b75ef66b9d11d37006aab000/standard/expressions.md#12813-null-conditional-element-access
>
> Next up, we discussed a potential compiler bug/specification bug. This has been open for a long time, but was recently resurfaced and we wanted to investigate to clarify our definitions. The question hinges on what the definition of what a non-nullable value type is. If a pointer is a non-nullable value type, then the rules as written state that the type would have to be `Nullable`, which is indeed illegal. But if pointers are not non-nullable value types, then the cases would fall through to the last bullet of the spec and it should just work, as the specified transformation would be legal for a pointer. Certainly on the surface, pointer types are nullable: `int* i = null;` is legal, as is comparing them with `null`. Given that, and the definitions in [§8.2.1](https://github.com/dotnet/csharpstandard/blob/41694caebb0fb759b75ef66b9d11d37006aab000/standard/types.md#821-general), we are comfortable treating this as a compiler bug, and will fix it to work. We will also leave the decision on clarifying the specification further to the ECMA 334 committee.
>
> #### Conclusion
>
> Null-conditional expressions that produce a pointer type not being allowed is a compiler bug and will be fixed as such.