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

### 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_