Simplify use of child scopes inside computation expressions

I propose to add a mechanism that allows for implicit use of builder methods in child scopes when being inside of a computation expression.

Today, we have to start new CEs when not being at top level scope of a surrounding CE.

In this example, a second `task` workflow has to be started in order to be usable in the child scope of the `let! b ...` body:

```fsharp
task {
let! a = Task.FromResult 1.0
// a new language scope means also: start new CE
let! b = task {
let! c = Task.FromResult 2.0
let! d = Task.FromResult 3.0
return c + d
}
return a / b
}
```

*This would become*:

```fsharp
task {
let! a = Task.FromResult 1.0
let! b =
// 'task' builder instance (or a 'fork' of it) is implicitly used
let! c = Task.FromResult 2.0
let! d = Task.FromResult 3.0

// return might also be implicit
c + d
return a / b
}
```

In addition, it could be possible to introduce an *anonymous bang*, so that this:

```fsharp
task {
let! three = task {
let! tmp = Task.FromResult 1
return tmp + 2
}

return three
}
```

*becomes this*:

```fsharp
task {
let! three = (!! Task.FromResult 1) + 2
return three
}
```

(I use !! in the example as a placeholder for the anonymous-bang operator.)

##

## Pros and Cons

* Reduce boilerplate code
* The syntax feels more natural, since using scopes is a common thing in F#
* It would simplify both readability and writability of code. Think of an update monad: It would almost look like imperative code. Writing such code today, I got interrupted by declaring new "update" workflows all the time.
* The *anonymous-bang* would increase the expressiveness of computations where arithmetic operations are a key feature and it would make custom arithmetic operators like `.+`, `.*`, etc. ambiguous. In C#, this is also possible today, where you can write something like this: ` (await Task.FromResult(new [] {1,2,3})).Select(x => x + 1); `
* In other languages that have async/await hardcoded (e.g. C# and Typescript), this is already possible today and I personally use those features often.

The disadvantages of making this adjustment to F# are not obvious to me from a users point of view.

## Extra information

Estimated cost (XS, S, M, L, XL, XXL): I can't tell because I'm not familiar with the F# compiler code. I guess it might be quite complex (L - XL?)

Related suggestions:
* https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1087-resumable-code-and-task-builder.md

## 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 proposed child-scope and anonymous-bang examples, then read the related RFC FS-1087-resumable-code-and-task-builder.md. The issue names no implementation files or tests; done would require a decided language design specifying implicit builder use and anonymous-bang semantics.

Written by the indexing model from the issue text.