Nullness feature request- parser recovery for ` null | ..`

[T-Gro]

Issue description

Parser recovery rule for a mistake of writing null | type instead of type | null.

Examples: let notAValue: null | string = "hi"

test.fs(1,21): error FS0010: Unexpected symbol '|' in binding. Expected '=' or other token.

let getLength (x: null | string) = x.Length

test.fs(1,20): error FS0618: Invalid literal in type

test.fs(1,16): error FS0018: The two sides of this 'or' pattern bind different sets of variables

test.fs(1,37): error FS0072: Lookup on object of indeterminate type based on information prior to this program point. A type annotation may be needed prior to this program point to constrain the type of the object. This may allow the lookup to be resolved.

Choose one or more from the following categories of impact

• [ ] Unexpected nullness warning (false positive in nullness checking, code uses --checknulls and langversion:preview).
• [ ] Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview).
• [ ] Breaking change related to older null constructs in code not using the checknulls switch.
• [ ] Breaking change related to generic code and explicit type constraints (null, not null).
• [ ] Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotations).
• [ ] C#/F# interop issue related to nullness metadata.
• [X] Other (none of the categories above apply).

Operating System

Windows (Default)

What .NET runtime/SDK kind are you seeing the issue on

.NET SDK (.NET Core, .NET 5+)

.NET Runtime/SDK version

No response

Reproducible code snippet and actual behavior

No response

Possible workarounds

No response