Activate the extension automatically

[vogelsgesang]

So far, the bazelWorkspace view, listing the available build targets,
was only shown after running the first Bazel command, e.g., through
the command pallete. This behavior was probably unintended and is rather
cumbersome for people which want to inspect the available Bazel targets.

The chain of events which lead to this behavior are:

• The bazelWorkspace view is only shown when the
  vscodeBazelHaveBazelWorkspace context variable is set.
• This context variable is unset by default, and hence the view is
  hidden initially.
• As soon as the first Bazel command is run from the command pallete,
  the extension was activated.
• As part of activating, the extension detected that there is in fact
  a Bazel workspace and hence it set the vscodeBazelHaveBazelWorkspace
  context variable, unhiding the bazelWorkspace view.

This commit fixes the issue by activating the extension as soon as one
of Bazel's build files is found.

Furthermore, all pre-existing activation events were redundant since
VS Code 1.74 which started to automatically infer activation events
based on the contributions provided by an extension

BEGIN_COMMIT_OVERRIDE
fix: Activate the extension automatically (#344)
END_COMMIT_OVERRIDE

[cameron-martin]

It might be better using the workspaceContains activation event here, looking for the MODULE.bazel or WORKSPACE file. That way, the activation cost is only paid if the user is opening a bazel workspace.

[vogelsgesang]

Based on comments like #72 (comment)

[the] directory might not have a BUILD file (it could be some random place within the overall bazel workspace)

I was initially unsure, whether such a workspaceContains trigger would be sufficient in all cases.

But reading that thread again, I now think that the comment was about opening a folder somewhere in the folder hierarchy between two BUILD files. I.e., there would still also be a BUILD file in the subdirectory. As such, I think using workspaceContains should be fine?

I updated the pull request to use workspaceContains now. This certainly solves my use case, and we can always switch to onStartupFinished if anyone runs into issues in the future

[jfirebaugh]

Let's keep onLanguage:starlark, on the off chance case someone opens a .bzl file in a workspace without any of the other workspaceContains triggers. Doesn't hurt.

[vogelsgesang]

According to VS Code's documentation, the onLanguage:starlark activation event is unnecessary:

Beginning with VS Code 1.74.0, languages contributed by your extension do not require a corresponding onLanguage activation event declaration for your extension to be activated.

Note that this extension only support VSCode >= 1.85.0

[vogelsgesang]

I updated the description of this PR to also include the reasoning on why I removed all pre-existing activation events

[jfirebaugh]

Got it, thanks, sounds good!