Create AuthoritiesChange digest item in correct block

[svyatonik]

This is rather major light-related issue (my bad that it is found too late), so I'll describe it in details. Please note, that now light client doesn't relies on AuthoritiesChange digest item => the situation I'm describing will be valid once #1669 is in.

Original requirements: header of the block A should include AuthoritiesChange(new_authorities) digest item if authorities set changes at this block. This new set from the digest item is used by light client starting from next block B.
The issue: AuthoritiesChange digest item actually appears in the block B (instead of A), meaning that B itself is checked using previous authorities set on light client => verification will fail.
Why: the digest item is emitted by Consensus::on_finalize and authorities change occurs in Session::on_finalize. Unfortunately, Consensus is finalized before Session => digest item is scheduled for the next block.
Possible solutions I have considered:

1. originally introduced in this PR: change modules initialization+finalization order to: initialize in declaration order (i.e. in the order they're declared in construct_runtime!) and finalize in reverse order. Currently it is: initialize and deinitialize in declaration order. This way (at least in node' runtime) we first call Session::on_finalize, then Consensus::on_finalize, thus emitting digest item in correct block. This isn't the best solution, imo - it relies on yet-undocumented init+fin order. But it is the (hacky) solution that requires least code changes;
2. remove direct authorities modification methods from Consensus && make something like Consensus::mutate_authorities. Emit AuthoritiesChange at the end of this call. There's a problem if authorities are changed several times in one block => we'll emit >1 digest items. Solving that would require modifications of already prepared Digest (i.e. breaking API - something like Digest::logs_mut(&mut self));
3. the same as in (2) but without introducing Consensus::mutate_authorities => we'll teach native how to treat multiple AuthoritiesChange items in single block - we'll take the last change. The bad thing is that if there are many changes within block (like currently - we're editing authorities one-by-one), there'll be a lot of AuthoritiesChange items (i.e. header could be huge);
4. allow explicit specification of finalization order in construct_runtime - that is similar to the (1).

The common problem of all solutions is that once #1669 is in, light client will fail to sync existing chains (even if we'll update full nodes with code that is able to serve finality proof requests). I could make a hackish workaround for that in Aura - if header verification fails, fallback to what we have now (i.e. remote execution of AuthoritiesApi::authorities()). But we need to decide whether we need this, or not. If I understand correctly, this won't affect syncing existing chains by full nodes (need check), because it changes runtime code => new wasm will be used on 'old' nodes.

[gavofyork]

Happy to break stuff in master now, so this can go in. Two alternatives for fixes:

• introduce an additional two on_ calls; on_post_finalize, on_pre_initialize. These allow system-level SRML modules to do exceptional stuff after the other modules are finished.
• introduce a dependency system whereby each module implements provides() -> Vec<Tag> and requires() -> Vec<Tag>. module init order starts with those that have no requires; fini order is the opposite. Tags are used (rather than explicit module identifiers) to generalise and avoid the need for specific module references where none currently exist.