Consider nested includes when checking for valid signers of a file.

**Is your feature request related to a problem? Please describe.**
The valid signers check does not consider nested includes when looking for signer addresses for a file.

**Describe the solution you'd like**
If a file is included by a content.json file and an address is in the signers field of its parent content.json file (or its parent or the parent of the parent and so on), that address should be considered a valid signer of the file, without having to mention it explicitly in the signers field(similar to how the zite address is always a valid signer).
**Reasoning:**
If a address is in the signers field on any node(=content.json) in the 'includes tree'(so to speak), it can always just 1) add itself to the next child node, 2) sign it, goto 1 and repeat until a leaf node is reached. This will achieve the same effect.
However, if things stay as they are now, any second address that is in a signers field along the tree below the first address, can remove the first address from any part of the tree that is below the second address. This is not possible when ZeroNet traces the 'includes tree' upwards and adds the addresses it finds in the signers field to the valid signers automatically, since the second address would have to remove the entry at a node higher up in the ' includes tree', which it can't do, because it is not a valid signer of that upper node.

**Describe alternatives you've considered**
Different data structures. It is (to the best of my knowledge) impossible to have moderation with different permission levels, without the lower level permission level moderators being able to sabotage the higher level ones (excluding the owner, of course). See Additional context for more detail.

**Additional context**
I was working on a moderation system for hubs, which does not rely on trusting that every privileged user(admin, mod or volunteer) is never malicious, while in power.

These are the proposed moderation levels:

- Owner: Can change anything(including html/js + root content.json + editing user data), appoints admins, mods, volunteers
- Admin: Can change anything(including data json + editing user data + hub config), appoints mods, volunteers
- Mod: Can change user content(editing user data), appoints volunteers
- Volunteer: Can change nothing, only clientside overwrite and prioritized reporting to mods/admin/owners
- User: Can change nothing, has ability to report things to volunteers/mods/admins/owners

This is the data layout I used(`-` annotates files `+` folders):
```
-content.json [1]
+data/
-content.json [2]
+owner/
-content.json [3]
+admins/
-content.json [4]
+L_admin/
-content.json [5]
+config/
-HubConfig.json
+mods/
-content.json [6]
+L_mod/
-content.json [7]
+users/
-content.json [8]
```
Where:

- [1]{root content.json} includes [2]
- [2] includes [3]{includes allowed}, [4]{includes not allowed} and [5]{includes allowed}
- [3] includes nothing
- [4] includes nothing and is a user_content content.json, where everyone can't post by default(using permission_rules `".*":** {files_allowed: "", max_size:0}`) and new admins are added by the owner using the permissions field.
- [5] includes [6]{includes not allowed} and [7]{includes allowed}
- [6] same as [4] only that mods will be added here, by either the owner or an admin.
- [7] includes [8]
- [8] includes nothing and is a user_content content.json, where everyone can post by default but is not allowed to write to a file that the database will recognize as 'moderation action'. The owner, an admin or a mod can grant a user the ability to perform mod actions, by adding them to the permissions field.

The idea was to:

- Add every admin address to the signers field in the include in [2] for [5] and to the permissions field in [4]
- Add every mod address to the signers field in the include in [5] for [7] and to the permissions field in [6]
- Add every volunteer address to the permissions field in [8]

This has a few nice properties embedded into its structure:

- posts of the owner cannot be altered by anybody.
- posts of admins (in `data/admins/[address]/`) cannot be altered by mods
- posts of mods can be altered by admins, but not by volunteers
- posts by users and volunteers can be altered by admins and mods, but not by either volunteers or users.
- The owner can alter everything.
- Owners can't appoint owners(because there only ever is one), admins can't appoint admins, mods can't appoint mods and volunteers can't appoint volunteers.
- Only users with a higher permission level are able to remove the extra permission of a privileged user. (Owner > admins > mods > volunteers)
- Very little complexity in JS: Owner, admins, mods, volunteers and users can use the same code for mod actions and posts, the only thing that changes is the path and a few extra checks.

If permissions were inherited by includes, an admin would be able to sign everything that the content.json, that has the admin in the signers field, signs. For example an admin would be able to sign the data.json file of any user, the content.json file of the mods([7]) and so on, basically everything within the `L_admin` folder.

Because this is not the case, each admin needs to be mentioned in every signers field of every content.json separately to be able to sign it, which an admin would be able to do on his own anyways(see reasoning above).
The problem with that is that a malicious mod could just remove an admins address from the signers field of [7], sign and publish [7] and with that, invalidate all user files that that admin edited in the past. They will remain invalid until the admin comes back and adds themselves back into [7]. During that time the data of the edited user(and in fact every user that had their content edited by that admin) is, at best, unavailable to newcomers and at worst deleted from existing peers.

This issue is mirrored from the [GitCenter ZeroNet repository](http://127.0.0.1:43110/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/repo/issues/view/?1P4w4Rvh4vS9r6G5xTiSh8qEW87EKZtnJB/12@1DfrA2M9Qra6stqT6tzwNMYNweswY54KAC)(you need to install ZeroNet to visit this link)