Permissions behavior when enabling module for tenant with already-existing permissionName in module descriptor

The current behavior is to silently ignore the new permission definition. This leads to the following potential issues:

1. Different modules could define permissionSets with (for example) different subPermissions, but the same permissionName, with no way to ensure which one will take effect except for load order
2. A module upgrade might reasonably want to create new "atomic" permissions and include them in compound permissionSets

Note

Assumption: we can allow overwriting permission sets by modules during install/upgrade but keep them immutable from the end-user viewpoint.

In the scope of this ticket we will only fix the behavior in mod-permissions that ignores updates to permission sets during module install/upgrade.

Open question: in case a user defines a mutable permission set with the same name as module-provided permission set we will override the user-created set. This problem should be addressed by scoping user created permission sets so that this problem never occurs.