add a workspace-peek command

[enricosada]

Scenario:

An editor open a directory (usually), and now need to know what's interesting inside, and that mean fsproj and sln files, to start.

This is a lot more important in new dotnet/sdk, because:

• restore. if not restored, a dotnet restore command should be run. ideally from a sln instead of multiple times. but if a root project exists, is ok too. But is not easy to know, but user does.
• mixed fsproj of old sdk and new sdk in same repo. happen a lot atm, to just support netcore/netstandard. usuallly they are in different sln, but not always.
• sln are not always used
• for initialization with project, the starting project matter a lot. really important with multiple framework

So an editor need to choose where to start, and FSAC can help.

Proposed

a new workspace-peek command who accept a directory, and return info about all sln/fsproj fast but inaccurate.
i want to emphatize fast and inaccurate, because my idea is just a quick peek, to better understand how continue. Implementation will do just xml parsing/grep, not real msbuild automation.
as usual project will do the detailed parsing and initialization after.

Info returned for each fsproj:

• lib or exe?
• sdk type? old sdk vs project.json vs dotnet/sdk vs fsharp.net.sdk.
• target frameworks? one or more?
• graph of p2p or topological sort or weight of importance (useful for picker to sort choices for user)
• tags, like test, fable, fez (soon™️), paket etc

for sln, just proj list is enough

@Krzysztof-Cieslak @rneatherway @kjnilsson feedback?
this is easier to move code from editor side to FSAC, and implement easier nice UX sharing code who already exists there anyway (what is the sdk type? etc).

Possibile alternatives:

• a more accurate workspace but slower initialization step, with real msbuild automation, to replace project, but need some feedback about request/response, because some choices should be left to user. So maybe later

[Krzysztof-Cieslak]

👍 for fast and inaccurate version, Ionide definitely needs it, right now initialization strategy is bit random, what was result of some limitations on Code side, and this would let us to make it nicer- especially that latest Code includes better workspaceContains activation event.

[rneatherway]

Seems like a very good idea to me.

[enricosada]

implemented with #191