Add permissions property to deno.json #25651

Add the property permissions to the deno.json file.
This includes updating the configuration and the schema.

Based on Web Worker permissions, with the only difference that permissions cannot be inherited because there is no parent.
Permissions are defined per command: The permission keys are file names for deno run or task names for deno task, the permission values are the respective permissions.

// deno.json
{
  "tasks": {
    "dev1": "deno run main1.ts",
    "dev2": "deno run main2.ts",
    "dev3": "deno run main3.ts",
    "dev4": "deno run main4.ts"
  },
  "permissions": {
    "main2.ts": {
      "read": true
    },
    "dev3": {
      "net": ["jsr.io:443"]
    },
    "main4.ts": {
      "read": true,
      "write": true,
      "net": ["jsr.io:443"]
    },
    "dev4": {
      "read": true,
      "write": "./",
      "net": true
    }
  }
}

deno task dev1/deno run main1.ts has no permissions.
deno task dev2/deno run main2.ts has inherited read permissions from main2.ts.
deno task dev3 has inherited net permissions to jsr.io:443 from dev3.
However, deno run main3.ts has no permissions unless it is run by the task dev3.

deno task dev4 is a special case because there are permissions for the task and the file.
In this case, it has permissions only if both instances have it, and even then, only the most restrictive ones.
So it has the permission to read anywhere, write only to the project folder, and access net only to jsr.io:443.

Maybe only file names as permission keys are enough, making it a bit simpler.
On the other hand, permissions: "inherit" could be implemented by defining another permissions property in the permissions values. Then permission keys could inherit permissions from other permission keys.
Another approach would be to add a new permission to deno run, then the permission keys can be any string.
E.g. deno run --permissions=offline main.ts / deno run -P=offline main.ts
That depends on feedback.

In any case, this declutters the deno run commands.