chore: Update dependencies

[CsCherrYY]

Also update vscode engine to 1.66.0 (the first version using node 16)

[CsCherrYY]

test failed due to VS Code 1.75.0, in the previous versions (includes 1.74.3) it runs successfully, I'll take a look.

[Eskibear]

what's changed upstream, causing you have to wait 1000ms?

[CsCherrYY]

not sure what's changed there, some findings:

• See the current implementation:

  vscode-gradle/extension/src/test/unit/gradleDaemons.test.ts

  Lines 267 to 282 in d2bb901

  	gradleDaemonsTreeDataProvider.refresh();
  	gradleDaemonsTreeDataProvider
  	.getChildren()
  	.then((_children: vscode.TreeItem[]) => {
  	assert.strictEqual(_children[0].description, "BUSY");
  	})
  	.catch(reject);
  	// This call will return the correct results (longReply)
  	gradleDaemonsTreeDataProvider.refresh();
  	gradleDaemonsTreeDataProvider
  	.getChildren()
  	.then((_children: vscode.TreeItem[]) => {
  	assert.strictEqual(_children[0].description, "IDLE");
  	resolve(undefined);
  	})
  	.catch(reject);

• this test case aims to test if a "urgent" refresh will skip the running process that fetches the daemon status (called "future result", IDLE here) and return the "current result" (BUSY here).

• This case includes two parts:

  • part 1: The refresh() call in line 275 will skip the getChildren() call in line 269 to return the "current result",
  • part 2: The getChildren() call in line 277 can finish with "future result" successfully since it will not be interrupted by any refresh() call.

• when using the original test code and tested in VS Code 1.74.3, the debugger view shows the result is not expected, but the test case passed. Not sure why.
  
  

• So I just sleep here to distinguish two parts, workaround here for now and make it behave more "manually".