Add support for Autos window

[cmeeren]

According to the VS2017 docs (and observed in practice), the Autos window does not work in F#. I suggest adding support for the Autos window. It's a great help in C# and VB debugging, and while I spend far less time debugging with F# and functional architectures makes debugging generally easier, the (lack of) tooling makes some aspects of F# debugging more painful than it needs to be. The Autos window could alleviate some of that pain.

[xperiandri]

Great idea.
Maybe @Pilchie or @dsyme can point to Roslyn implementation?

[Pilchie]

CSharpProximityExpressionsService

[dsyme]

From the C# source code:

    /// Given a position in a source file, returns the expressions in close proximity that should
    /// show up in the debugger 'autos' window.  In general, the expressions we place into the autos
    /// window are things that appear to be 'side effect free'.  Note: because we only use the syntax
    /// tree for this, it's possible for us to get this wrong.  However, this should only happen in
    /// code that behaves unexpectedly.  For example, we will assume that "a + b" is side effect free
    /// (when in practice it may not be).  
    /// 
    /// The general tactic we take is to add the expressions for the statements on the
    /// line the debugger is currently at.  We will also try to find the 'previous' statement as well
    /// to add the expressions from that.  The 'previous' statement is a bit of an interesting beast.
    /// Consider, for example, if the user has just jumped out of a switch and is the statement
    /// directly following it.  What is the previous statement?  Without keeping state, there's no way
    /// to know.  So, in this case, we treat all 'exit points' (i.e. the last statement of a switch
    /// section) of the switch statement as the 'previous statement'.  There are many cases like this
    /// we need to handle.  Basically anything that might have nested statements/blocks might
    /// contribute to the 'previous statement'