DAORegistry scheme specification

Currently, we have this implementation: https://github.com/daostack/arc-hive/blob/master/contracts/DAORegistry.sol

With the defined interface:
```solidity
propose(address _avatar) public;
register(address _avatar, string memory _name) public onlyOwner;
unregister(address _avatar) public onlyOwner;
isRegistered(string memory _name) public view returns(bool);
```
The DAO avatar will own this contract, and so the question becomes do we use the generic actions scheme to interact with this contract, or do we create a new scheme to handle these registries.

For example, we can define the RegistryScheme:
```solidity
proposeRegisterDAO(Avatar _avatar, string memory _registryName, string memory _proposedName, Avatar _proposedAvatar);
proposeUnregisterDAO(Avatar _avatar, string memory _registryName, string memory _proposedName, Avatar _proposedAvatar);
executeProposal(bytes32 _proposalId, int256 _param) external onlyVotingMachine(_proposalId) returns(bool);
```
naive implementation here: https://github.com/dOrgTech/DAOfeatures/blob/master/features/registrars/contracts/DAORegistryScheme.sol

This will use the proposal pattern with the DAO avatar address and the `_registryName` as the mapping keys to the registry that it owns and is allowed to update.

When a proposal passes, `executeProposal` depending on the scheme parameters 1/2 (add/delete) it will call either proposeRegisterDAO/proposeUnregisterDAO.

We could generalize this further by instead of having the proposal functions use _proposedAvatar, it could be a struct with many other fields that are accessed depending on enumerated `uint` types that are mapped to strings `registryName`.

Depending on the types it would update different registries in which the structure is well defined beforehand, and this would facilitate better upgradeability