[PVM, DAC] Admin proposals

[evlekht]

Why this should be merged

This PR does 2 things:

• introduces feature "admin proposals"
• forbids addressStateTx to edit consortium bit

Admin proposals are proposals that can be created only by allowed role (on proposal-type basis) and will be executed immediately after creation without any voting. So, they're more like admin actions than proposals.

How this works

Admin proposals

PR adds new proposal type that wraps other proposal types.

type AdminProposal struct {
	OptionIndex uint32 `serialize:"true"`
	Proposal    `serialize:"true"`
}

If proposal of this type is inside of addProposalTx, than tx will try to create admin proposal.

On execution node will check if wrapped proposal type actually allows be used as admin proposal, than it will check that proposer has address state role that allows him to create admin proposals of this type.

If all checks successful, node will create proposal state with already existing vote for specified option index and then will its id as finished proposal. So, on next block-build, node will create finishProposalsTx with this proposal.

AddressStateTx

If BerlinPhase is active, node will reject addressStateTx that tries to edit consortium bit, even if its signed by admin role.

This PR also moves address state definitions from txs to their own package, cause its now used from dac pkg as well and this is causing cycle deps.

How this was tested

Unit-tests, integration test

[knikos]

great job and very goot test coverage!!! just some comments related mostly to formatting issues.

only one thing to note: I would add a test that checks whether an Admin Proposal CanBeFinished() immediately after being created just to have that extra unit test.