Extended CORS Permission AKA Should Zites be Allowed to Download/Modify/Delete Optional Files with CORS?

**Is your feature request related to a problem? Please describe.**
The problem as of now is that even tho the `fileNeed` cmd is not CORS enabled, `fileGet` with the `required` argument set to `true` acts just the same way as `fileNeed` does.
First of all, I completely join the opinion [that the user is at risk when allowing a zite to basically download all optional files of another zite](https://github.com/HelloZeroNet/ZeroNet/issues/1014#issuecomment-314519444), so that functionality should be limited, thus with this _I propose to always set the `required` argument to `false` in the CORS plugin code_.
With that in mind tho, I'd still like to discuss on whether there might be a different solution to the problem which is that a zite might want to download or change files of another zite.

**Describe the solution you'd like**
As the user currently has to accept the CORS permission for a zite, and to recap this allows the requesting zite to use all CORS enabled cmds just as if they were from-and-to the executing zite, I'd additionally like to propose the implementation of a "CORS extended" request cmd, which also enables downloading files as well as [writing to files](https://github.com/HelloZeroNet/ZeroNet/issues/1811) through the CORS system (download and write could also be split up into two separate requests, considering the user should have full power over what they allow and what not).
With the "CORS extended" permission, a zite could potentially then be given full cmd operability in the context of another zite. Of course, this should be thought through thoroughly, but I think quite a few zites would profit from this. If this "CORS extended" permission is implemented, one expected behaviour would be as follows:

- No CORS -> `fileGet` returns "No permission"
- Basic CORS -> `fileGet` can only return the data of the file (but `required=true` will have no effect)
- Extended CORS -> `fileGet` can return the data of the file, and if `required` is `true`, then download of the file may be initialized

Through this permission, the optional file system could be largely widened out to also function cross-zite (and would thus make optional file management possible without a workaround, as I describe it as an alternative below).

**Describe alternatives you've considered**
An alternative workaround which I am also using right now (see the ZeroTalk topic linked below) for the `optionalFileDelete` cmd, is to redirect to a "API" page of the zite where the optional file lies (passing the specific file via the query string), delete the optional file there, and then redirect back to the zite that requested deletion.

**Additional context**
You can find more on how I came to create this issue here: http://127.0.0.1:43110/Talk.ZeroNetwork.bit/?Topic:1556467817_1Mi7rUdBpQc99kfuvippGxgEbM7ZKdSXUD

I have basically created three zites (of which one is not that relevant to this issue, but is still a good example):
1. The zite where the optional files are stored:
http://127.0.0.1:43110/1D2xzWx2oG8oUiMpKvygeoyYL7uJXFMp8k
https://gitlab.com/AnthyG/sample-image-data-zite
2. The zite where the data from the previous zite can be viewed:
http://127.0.0.1:43110/1NHXyHdJimWTCcYByRSM7RGVfUkixwjf41
https://gitlab.com/AnthyG/sample-image-view-zite
3. Also a zite where the data from the previous zite can be viewed (but it uses a library I created for this whole thing):
http://127.0.0.1:43110/1PmkreYrHALCPaPQx3h9Ht8oQzjCKpA3n
https://gitlab.com/AnthyG/sample-image-view-js-library

I think it should also be made clearer, on what the difference is between using CORS through prefixing the `inner_path` of a file with `cors-ziteaddress` and using CORS through the `as` cmd. In my experimentation I have e.g. found out that I can use `optionalFileInfo` through `as` but not with `cors-ziteaddress` even tho I thought that that should be the opposite after reading this line https://github.com/HelloZeroNet/ZeroNet/blob/e687d5db69d5466b06a88b49d9a569ef7855b468/plugins/Cors/CorsPlugin.py#L30