Support `inref` in computation expression operations

**I propose we support accepting `inref<'T>` as the first parameter of computation expression operation**

``` F#
[]
type CreateOperation<'a> = {
Item : 'a
PartitionKey : PartitionKey voption
RequestOptions : ItemRequestOptions
}

type CreateBuilder<'a> (enableContentResponseOnWrite : bool) =
member _.Yield _ =
{
Item = Unchecked.defaultof<_>
PartitionKey = ValueNone
RequestOptions = ItemRequestOptions (EnableContentResponseOnWrite = enableContentResponseOnWrite)
}
: CreateOperation<'a>

/// Sets the item being created
[]
member _.Item (state : inref>, item) = { state with Item = item }

/// Sets the partition key
[]
member _.PartitionKey (state : inref>, partitionKey : PartitionKey) = {
state with
PartitionKey = ValueSome partitionKey
}

/// Sets the partition key
[]
member _.PartitionKey (state : inref>, partitionKey : string) = {
state with
PartitionKey = ValueSome (PartitionKey partitionKey)
}

/// Sets the request options
[]
member _.RequestOptions (state : inref>, options : ItemRequestOptions) = {
state with
RequestOptions = options
}
```

**The existing way of approaching this problem in F# is not using `inref`s and causing structs to be copied**

## Pros and Cons

**The advantages of making this adjustment to F# are performant object builders using computation expressions and value type state**

**The disadvantages of making this adjustment to F# do not exist**

## Extra information

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

**Related suggestions:** No

## Affidavit

Please tick these items 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] This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to [the compiler and tooling repository](https://github.com/dotnet/fsharp)
* [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
* [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

Please tick all that apply:
* [X] This is not a breaking change to the F# language design
* [ ] 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.

No repository files, tests, or entry points are named. Start with the computation-expression custom-operation rules and the provided CreateBuilder example; determine the language-design scope for accepting an inref state parameter, then document the decision and add coverage for the shown forms.

Written by the indexing model from the issue text.