refactor(cli/flags): change allow_read/write/net types from bool to Option<Vec<T>>

[magurotuna]

This PR refactors cli/flags.rs and runtime/permissions.rs so that allow_read, allow_write and allow_net themselves will have allowlists.

In the current implementation, the allowlist for the net flag is stored in net_allowlist: Vec<String> and the presence of allow-net flag is stored in allow_net: bool. However, if we run deno with deno run --allow-net=example.com, allow_net will be false even though allow-net flag is present - which looks confusing to me. The relation between them is as follows:

command	allow_net	net_allowlist
deno run foo.ts	false	vec![]
deno run --allow-net foo.ts	true	vec![]
deno run --allow-net=example.com foo.ts	false	vec!["example.com"]

So in this PR, net_allowlist is removed and the type of allow_net is changed to Option<Vec<String>>. In this way, both the presence of the flag and allowlist values can be stored well and simply like:

command	allow_net
deno run foo.ts	None
deno run --allow-net foo.ts	Some(vec![])
deno run --allow-net=example.com foo.ts	Some(vec!["example.com"])

[crowlKats]

I am not too much of a fan that empty vec means all perms...

[nayeemrmn]

LGTM

I am not too much of a fan that empty vec means all perms...

The Flags struct should be a close representation of the flags that were passed, so this is correct there. With PermissionOptions it's a bit more questionable but it's simple for the structure to carry forward from Flags. It would definitely be bad for storing runtime permission state, but this change doesn't do that. We still have the { global_state, granted_list, denied_list } for that.

[magurotuna]

Initially I considered creating some original enum like

enum AllowFlag<T> {
  Disallow, // corresponds to None
  AllowAll, // Some(vec![])
  AllowList(Vec<T>), // Some(vec![...])
}

and then allow_net: AllowFlag<String>

[crowlKats]

The Flags struct should be a close representation of the flags that were passed, so this is correct there.

true

Initially I considered creating some original enum like

enum AllowFlag<T> {
  Disallow, // corresponds to None
  AllowAll, // Some(vec![])
  AllowList(Vec<T>), // Some(vec![...])
}

and then allow_net: AllowFlag<String>

I do like that solution

[crowlKats]

After some thinking, the current behaviour of the PR sounds reasonable to me.
This does also make life a tad easier for #8617 as perm flags that take vals are actually with the same signature of Option<Vec<String>> with the exact same behaviour as this PR.

[bartlomieju]

I'm not sure if this solution is better/easier to understand, but let's land it and see if there's any confusion. LGTM, thanks @magurotuna