Added #3520: Add ability to map users to multiple companies with FullMultipleCompanySupport

[Toreg87]

This is #9821 rebased to the latest version. @snipe is working on a similar feature in #17140 and maybe this is useful. I use this in my production environment since a few years. Below is the original description.

We have a hierarchical set of companies grouped in multiple layers:
a) the upper layer must have access to all companies
b) the lowest layer must be scoped to only one company
c) the middle layer must have access to multiple companies of the lowest layer, but not all of them

a) and b) is possible with FullMultipleCompanySupport and super user, but c) is currently not supported.

To accomplish this, I propose the concept of "mapped" companies.
Users with a mapped company can see and update all resources of the mapped company according to the users permissions, just like the "primary" company.

A new mapping table is created and linked to users and companies and the company scoping function is updated accordingly.
The mapping table only contains additional mappings, not the "primary" company of the user.
In the user edit view a new tab is created to map users to companies.

The validation logic must be changed for this. Currently a scoped user can't change the company.
Now it must be possible for users with mapped companies to choose between companies.
To do this, two changes are needed:

• the company selectlist gets scoped to the primary and the mapped companies
• a new validator is introduced to validate if the user is allowed to choose a company or if a company is required. This validator handles input through the UI and the API

The logic if a user is edited must be changed accordingly:

• If a different "primary" company is assigned to a user, the mapping table must be updated.
• Bulk editing this must also be supported.
• If a user gets cloned, the mappings must be cloned.

I implemented this feature with performance and backward compatibility in mind. There is no overhead if FullMultipleCompanySupport is disabled.
The feature is fully optional, there is only minimal overhead if FullMultipleCompanySupport is enabled and no mappings are used.

[uberbrady]

I can actually read this, and that's already a huge deal. I know what this is doing, and why it's doing it. I still kinda feel like there's a different direction I'd like us to go in for this general feature-set, but that's not written, while this is. And that may be enough. I'm going to talk with @snipe to work through how we think is the right way to handle this, or if this is "good enough" - it may be.

That being said, even if we choose not to take this particular attempt at this - I can't thank you enough for providing it to us; it could really help solve a problem that many of our users are having. We're going to have some really earnest talks about it. Stay tuned :)