Multiple extension installations

[kronosapiens]

Closes #968

Change internal network-level extension bookkeeping to support an arbitrary number of simultaneous extensions with the same identifier. Backwards-compatible with existing extensions.

New functionality is oriented around the address of the extension, rather than the bytes32 identifier, so all extension-management functions (upgradeExtension, etc) now call for the address of the extension.

To check if an extension is installed, use getExtensionColony, passing in the address of the extension. The function will return the address of the installed colony, if installed.

[area]

The main problem I'm seeing here is that this is currently not backwards compatible. If I am an old colony version, and network has been upgraded, I call installExtension, which calls installExtension on the upgraded network, which records the installation in multiInstallations. If I then call deprecateExtension, or one of the other extension management functions, I call a deprecated one (because I am not an upgraded colony), which fails because of the require in migrateToMultiExtension - even though I am an old colony, the installation is in multiInstallations.

[kronosapiens]

@area Ah good observation, I had not thought about the network/colony upgrade discrepancy. Perhaps we can add a version check in installExtension which will use installations for v6 colonies and multiInstallations for v7.

[area]

Broadly speaking, I think a decisions need to be made based on what the client currently does and / or how much bandwidth the frontend team have to accommodate changes. At the very least, we need designs for and they'll need to implement the mechanism for calling the migrate function, and possibly more beyond that depending on what events they use for finding extensions.

[area]

You've ended up doubling up on the isContract check in the refactoring. I'd leave it in isOwnExtension, and delete the standalone one here.

[kronosapiens]

I thought about that, but the problem is that the contract check might be useful feedback (i.e. if someone tries to make an arbitrary tx to a user address, the error shouldn't be colony-cannot-target-own-extensions. On the flip side, if we remove it from isOwnExtension, that function could throw in a confusing way. So I sort of think it's best this way, even if a bit redundant. The other idea is to have the isContract check inside isOwnExtension throw an error, which is a little bit of a mixup for a boolean-valued function but I could roll with it.