Make GovernanceStaker more generalizable and extensible

[apbendi]

We want the core GovernanceStaker contract to be as general and extensible as possible, so that DAOs can assemble a version of staker that works for them, including with customizations as necessary. To accomplish this, we can make parts of the system extensible via inheritance, allowing the core mechanics of the system to be customized or assembled using appropriate extensions. This issue aims to summarize a few different axes along which this extensibility should be implemented. These tasks should be handled as multiple PRs. This issue is intended as a tracking issue for the goal of extensibility writ large.

• Make GovernanceStaker itself an abstract contract & convert the GovernanceStakerHarness into an implementation that is exercised in the unit and invariant tests #48
• Make the "name" and "version" parameters passed to the EIP712 constructor parameters in the GovernanceStaker constructor that must be passed by the inheriting implementation #50
• Make most (all?) internal and external methods virtual to allow inheriting implementations to override them if needed #52
• Consider if some external methods should be public instead
• Consider if some storage vars should be made private with external/internal/public getters
• Make the use of throughout Staker instead use an interface that takes two addresses as its arguments. #60
  • Rename the existing DelegationSurrogate contract to something like DelegationSurrogateIVotes and inherit from IDelegationSurrogate
• Make the _fetchOrDeploySurrogate a virtual, abstract method. Implement an extension like DelegationSurrgoateIVotesDeployer that implements _fetchOrDeploySurrogate to deploy a DelegationSurrogotateIVotes #73
• Move the permitAndStake and permitAndStakeMore methods into an (optional) extension (not all governance tokens will have permit methods) #68
• Change the STAKE_TOKEN to be a simple IERC20 in GovernanceStaker instead of IERC20Delegates #47
• Move signature based methods into their own extension #70 Should we also move signature based methods into their own extension? Presumably most DAOs would want them, but it's possible in the future they may be obsoleted by new schemes for account abstraction, new signature schemes, etc...
• Consider: modularize the surrogate abstraction even further by moving the job of surrogate look up (i.e. the surrogates mapping) into the extension. This could also allow us to implement a version that uses create2 to calculate the surrogate address and therefore avoid the lookup altogether #79