Avoiding "haywire" CPU searches by ignoring `.snakemake/` folders when using this extension

[irm-codebase]

Taken from here snakemake/snakemake#3033 (comment)

Is your feature request related to a problem? Please describe.
This issue is inspired by microsoft/vscode#225957.

In short: most IDEs are unaware that .snakemake/ folders should not be searched. If your workflow is big enough, this can lead to file watchers (which enable search functions and refactoring) to go ballistic due to the large number of conda environments, consuming a lot of CPU.

This slows down working with the tool in cases were it occurs, and is quite unintuitive to debug.
Here is the result in VSCode (in this case, a single core thermal throttles for several minutes).

Similarly, there is a lot of "interpreter/environment spam" because conda picks up all the environments created by snakemake.

This happens in the terminal

And in IDEs (here's VSCode)

Describe the solution you'd like
This kind of 'spam', and particularly the CPU spikes, could be avoided by ignoring the .snakemake/ folder.

Describe alternatives you've considered

Placing this configuration in settings.json will solve CPU issues in VSCode. The problem is that you generally do not want to commit IDE settings to repositories, so having this in the extension would be better.

{
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/*/**": true,
        "**/.hg/store/**": true,
        "**/.snakemake/**": true // avoid snakemake environment CPU spikes
    },
    "search.exclude": {
        "**/node_modules": true,
        "**/bower_components": true,
        "**/*.code-search": true,
        "**/.snakemake": true  // avoid slow searches
    },
    "python.analysis.exclude": ["**/node_modules", "**/__pycache__", ".git", "**/.snakemake"]  // unsure if this helps yet
}

[johanneskoester]

THis is indeed a very reasonable idea. A PR would be very welcome.

[irm-codebase]

@johanneskoester glad to give it a try! See #41