Checked arithmetic operators

# Checked arithmetic operators

The C# team is considering to add [checked operators](https://github.com/dotnet/csharplang/issues/4665): `static T checked operator +(T lhs, T rhs);` which will be preferred in `checked` contexts, and only consider the regular (infer checkedness from compiler switch) operator if the signature of the checked operator does not fit. In contrast, when not in a checked context, checked operators will be ignored.

Although F# reserves `checked` as a keyword, my guess is that as with `event` and `sealed`, attributes will be used.
```fs
open System
type C =
{ c : int }
static member (+) ({ c = x }, { c = y }) = x + y
[]
static member (+) ({ c = x }, { c = y }) = Checked.(+) x y
```
With #96:
```fs
open System
type C =
{ c : int }
static member (+) ({ c = x }, { c = y }) = x + y
[]
static member (+) ({ c = x }, { c = y }) =
open Checked
x + y
```
This will emit `op_Addition` and `op_AdditionChecked`. If a checked operator is defined without the regular (infer checkedness from compiler switch) equivalent, an error will be raised.

C# will imply a `checked` scope inside implementations of checked arithmetic operators. Not sure if F# should follow.

The existing way of approaching this problem in F# is to write `op_AdditionChecked` directly that can only be used in C# once implemented in their end but being forced to write `op_AdditionChecked` when using from F#.

Whether allowing explicit unchecked operators is still unresolved from the C# side.

## Pros and Cons

The advantages of making this adjustment to F# are
> There is no way for a user to declare a type and support both checked and unchecked versions of an operator. This will make it hard to port various algorithms to use the proposed `generic math` interfaces exposed by the libraries team. Likewise, this makes it impossible to expose a type such as `Int128` or `UInt128` without the language simultaneously shipping its own support to avoid breaking changes.

The disadvantages of making this adjustment to F# are
> This adds additional complexity to the language and allows users to introduce more kinds of breaking changes to their types.

## Extra information

Estimated cost (XS, S, M, L, XL, XXL): S

Related suggestions: https://github.com/dotnet/csharplang/issues/4665 - the linked C# issue

## Affidavit (please submit!)

Please tick this by placing a cross in the box:
* [x] This is not a question (e.g. like one you might ask on [stackoverflow](http://stackoverflow.com)) and I have searched stackoverflow for discussions of this issue
* [x] I have [searched both open and closed suggestions on this site](http://github.com/fsharp/fslang-suggestions/issues) and believe this is not a duplicate
* [x] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:
* [x] This is not a breaking change to the F# language design
* [x] I or my company would be willing to help implement and/or test this

## For Readers

If you would like to see this issue implemented, please click the :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

Start with the linked C# issue and the existing F# approach of declaring op_AdditionChecked directly. Review the proposed attribute syntax, checked-context behavior, operator naming, and unresolved explicit-unchecked question; done requires an agreed language design plus implementation and tests for checked and regular operators.

Written by the indexing model from the issue text.