Adding the ability to query from the DevCanvas endpoint

[edkazcarlson-ms]

This PR introduces the DevCanvas plugin which will allow users to query data from the endpoint, making it so that users will see insights related to their code that we have cooked. This also adds the ability for result source service's to query based on files open as a whole as currently it only queries based on the project opened at the start.

What is NOT included in this PR:

• The ability to switch between endpoints at run time
• The ability to filter specific generator types or filter by rank
• Xaml
• Refreshing cache manually
• Grabbing files in the same directory as opened files

Currently I have a try catch in SarifErrorListItem that helps silently catch an exception that occurs from some strange sarif parsing. Currently in our sarif log response there is a driver under runs[].tools where we describe the tool, and then in the results we have a reporting descriptor under results[].rule where we have the name and guid of the tool. Looking at the code for result.GetRule(run) it seems to only search under tool.extensions and throws an exception when it fails to find, but the difference between the toolComponent for tool.driver and tool.extensions seems unclear and I'm not sure if I need to change the response our API sends or if there is a change we should make in the Sarif SDK itself.

Even once this gets approved I will not be merging. Instead I'll be using this as a feature branch which I'll branch off of when doing other smaller changes (explanations for the auth window, filtering to only ms users, etc).

[ShiningMassXAcc]

We need to restrict who gets the auth popups. Chris has a menu option to opt-in - ideally, we have this figured out automatically.

[ShiningMassXAcc]

Do we want to think about at least a short-term hack to prevent double show for people that have both extensions?

[edkazcarlson-ms]

@ShiningMassXAcc

We need to restrict who gets the auth popups. Chris has a menu option to opt-in - ideally, we have this figured out automatically.

Thought of some ways of doing it but they're all hacky.

• See if they are touching a repo that is a microsoft repo
• Somehow see their account on VS and initially validate it there
• Make 2 vsix where the plugin is enabled one one and disabled on the other. What do you have in mind?

@edkazcarlson-ms

• While not super great, I think the first bullet of checking the repo name against a master list of ADO instances we manually maintain is best. We need to make sure none of those instance names look like things that can't be leaked, but I expect there are none anyway. The main ones we need are anything in microsoft and msazure - but we can add quite a few more as well.

[edkazcarlson-ms]

Note: Will put this in description too, but even once this gets approved I will not be merging. Instead I'll be using this as a feature branch which I'll branch off of when doing other smaller changes (explanations for the auth window, filtering to only ms users, etc).