Implement a generic `propose` function in DAO.sol.

[Alberto Cuesta Cañada]

We could allow the DAO to accept proposals with arbitrary proposalData, so that a proposal can be done for any single function and parameter combination in the DAO contract. Instead of proposeVenture and proposeDividends we would have propose(contractAddress, proposalData)

There are some major setbacks:

1. It would require participants to manually check (if it's available) the contract code of every proposal in order to know what they are voting for.
2. It would also make room for memory abuse of the proposals storage variable.
3. We still have to keep the individuated enacting functions in the DAO.

Discuss.

[Alberto Cuesta Cañada]

1. I think this is an issue only of voter education. Each stakeholder has a limited number of votes to cast, and I assume that they would prefer to cast them for things they understand and that are legit enough. It would be expected that in such a situation, proposers would offer verifiable trace that their proposal is genuine, and those proposers that don't do it wouldn't be very successful.

2. In which sense could the proposals variable be abused? A proposal fee can be implemented to avoid DDoS style attacks. In terms of using proposals to store unrelated data, I don't know how much of an issue this is, since the caller pays for the required gas.

3. This is the most troubling one, but is also not directly related. I'm only looking to simplify the propose function. We will look later on if we can also simplify the enacting functions (I had a thought and made my head spin).

I can see that the potential for abuse is high, but on the other hand I can see that proposeVenture and proposeDividends are practically identical. I don't think that the new proposeNewFunding will differ in anything other than the parameters passed on to abi.encodeWithSignature(...).