feat(cli): add test permissions to Deno.test

[caspervonb]

This adds adds permissions to the test definitions which allows tests to run with different permission sets than the process's permission.

The change will only be in effect within the test function, once the test has completed the original process permission set is restored.

Test permissions cannot exceed the process's permission.
You can only narrow or drop permissions, failure to acquire a permission results in an error being thrown and the test case will fail.

Closes #9859

[piscisaureus]

@caspervonb Whatever happens - thanks for you contribution, we appreciate the time & effort you're putting into Deno!

That said, I don't really understand why this change is necessary. Maybe I'm just ignorant. However, can you give me the layman's explanation?

[caspervonb]

Thanks @piscisaureus.

This basic premise is to set up the permissions for a specific test case.

We can't do this with Deno.permissions.revoke because once permission is revoked you can't go back so there's no way to set up a test case with a certain set of permissions with the current permission API (@bartlomieju was kicking around the idea of adding it to Deno.permissions but this seemed more appropriate to me as it limits the impact to a very specific area).

The question of "How do I run a test case with x, y, and z" permissions does come up every now and then altho not that frequently it is something users find themselves needing when working with APIs that require certain permissions.

We set up these preconditions internally in our unit tests by not using Deno.test or even the test command at all so this simplifies the whole ordeal quite a bit and allows us to drop the whole unit test runner and just dogfood Deno.test.

The existence of the unit test runner is causing us to leak a bunch of internal details about the test runner as well which is not great.

---

TL;DR it is needed to set up the preconditions for a test that expects to have X permissions.

As a side effect, this will let us drop a few thousand lines of code that is used to support and implement our custom ad-hoc unit test runner and dogfood the user-facing test runner in our own test suite.

[bartlomieju]

Cleanly implemented. I think it's ready to land after addressing Bert's question regarding JSdoc. Nice work @caspervonb

[piscisaureus]

LGTM

[bartlomieju]

LGTM 🚀