`return reraise()` under an `async{}` context should be possible

At the moment, `return reraise()` inside a `try...with` block that is inside an `async{}` block is met with a compiler error. More info: https://stackoverflow.com/questions/7168801/how-to-use-reraise-in-async-workflows-in-f

The existing way of approaching this problem in F# is just wrapping the exception with a new one via `return raise(Exception("Some new msg", previousEx))`

## Pros and Cons

The advantages of making this adjustment to F# are:
- No need to needlessly wrap already-thrown exceptions into new ones, so that exception info is preserved without the need to investigate the innerException.
- No need to invent new keywords, `return reraise()` could just become valid.
- There's even a way to implement this natively already in .NET, thanks to the addition of ExceptionDispatchInfo (https://msdn.microsoft.com/en-us/library/system.runtime.exceptionservices.exceptiondispatchinfo(v=vs.110).aspx) in .NET4.5. F# compiler could just consume this when confronting `return reraise()`.

The disadvantages of making this adjustment to F# are:
- I believe there are not any disadvantages.

## Extra information

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

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