Allow pattern matching for exceptions in match expressions

I propose we allow pattern matching for exceptions in match expressions when the expression to be matched is a function call (or indexer/ property)
For example,

```fsharp
let l = [1;2;3]

let printer i =
match l.[i] with
| n -> printfn "Item: %d" n
| exception ArgumentException -> printfn "Invalid index"
| exception e -> printfn "An error unknown occurred: %s" e.Message

printer 10
```

The existing way of approaching this problem in F# is :
```fsharp
let l = [1;2;3]

let printer i =
try
match l.[i] with
| n -> printfn "Item: %d" n
with
| :? ArgumentException as e -> printfn "Invalid index"
| e -> printfn "An error occurred: %s" e.Message
```
Even though this isn't bad I think the former is clearer, more succinct and even easier to read (say, a new team member)

## Pros and Cons

The advantages of making this adjustment to F# are
1. Expressiveness
2. Clear and concise code (favoring readers over writers)
3. It Improves pattern matching in general
4. It's a nice and beautiful syntax
5. It's intuitive
6. [Efficient code via tail recursion](https://blog.janestreet.com/pattern-matching-and-exception-handling-unite/)

The disadvantages of making this adjustment to F# are
1. Implementation costs in the compiler
2. Multiple ways on doing the same thing
3. Might not be familiar to developers from other ecosystems (e.g C#) just learning F#

## Extra information

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

## 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 and existing F# examples in the issue, then read the 18-comment discussion to understand unresolved language-design concerns. Define the matching semantics and assess the compiler and test changes required; done means the proposal has an agreed design and implementation/testing path.

Written by the indexing model from the issue text.