`member P = expr`

I propose we make "this" binding optional in member declarations, so we get rid of the multiple `_.` (as in `member _.Foo() =`) in F# code. For reference see this comment from @vasily-kirichenko and the following four: https://github.com/fsharp/fslang-suggestions/issues/506#issuecomment-346688996

Instead of:

```fsharp
g { new ICodeGen with
member _.CodeLabel(m) = m
member _.GenerateDelayMark() = generateCodeLabel()
member _.GenLocal(ilty) = failwith "not needed"
member _.SetMarkToHere(m) = lab2pc.[m] <- instrs.Count
member _.EmitInstr x = instrs.Add x
member cg.EmitInstrs xs = for i in xs do cg.EmitInstr i
member _.MkInvalidCastExnNewobj () = failwith "not needed" }
```

We'd have:

```fsharp
g { new ICodeGen with
member CodeLabel(m) = m
member GenerateDelayMark() = generateCodeLabel()
member GenLocal(ilty) = failwith "not needed"
member SetMarkToHere(m) = lab2pc.[m] <- instrs.Count
member EmitInstr x = instrs.Add x
member cg.EmitInstrs xs = for i in xs do cg.EmitInstr i
member MkInvalidCastExnNewobj () = failwith "not needed" }
```

NOTE: This is only to remove the need of typing `_.` when there are no self references in the member body. It's not about implicitly binding `this`, in order to be able to self reference you would still need to bind `this` or any other identifier. The reasoning for this is [here](https://github.com/fsharp/fslang-suggestions/issues/506#issuecomment-346821054).

## Pros

- Cleaner syntax, it will likely make member declaration more uniform across code bases
- Avoid users making a decision in advance whether to bind "this" or not
- Avoid IDE warning when "this" binding is declared but is not used and is not `__`
- Backwards compatible

## Cons

> Concerns by @dsyme in a comment below and [here](https://github.com/fsharp/fslang-suggestions/issues/506#issuecomment-346821054).

1) Marginally less regular syntax - some instance members are member x.Method, some are member Method.
2) As a result it probably marginally disincentives the use of member x.Method bindings in F# methods - people might feel they are doing something wrong, when in fact it's pretty normal and reasonable to use member x.Method in members.
3) Property can be declared as `member x.P = expr`. Some programmers - especially those from ML-family languages - would take a while to grok that expr was evaluated once on each property use. We assessed that confusion on this point would be more likely with syntax `member P = expr`.

> Note by me: For 1) if IDEs remove the current exception for `__.` for the "Not used value" (which afaik is only a convention), hopefully there would be a transition period and then people will just get used to delete `__.` or `x.` when not used to remove the warning. About 3) properties in .NET are very convenient but make it easier to forget the expression is evaluated in every use, no matter if it's C# or F#, I think this is a tradeoff programmers need to be aware of.

## Extra information

Estimated cost (XS, S, M, L, XL, XXL): I guess it will affect mainly parsing and IDE tooling but I'm not sure how difficult to support the new syntax

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

Start with the proposed syntax examples and the linked discussion, especially the stated concerns about property evaluation and explicit self bindings. The payload identifies parsing and IDE tooling as the likely implementation areas, but no files or tests are named; done would require an agreed design plus implementation and coverage for the new member syntax.

Written by the indexing model from the issue text.