Weights for enacting candidates in paras inherent

[emostov]

This PR

• bubbles up the weight from the enact_candidate call and adds it to the returned weight of paras inherent enter. Previously we where not tracking the weight from enacting candidates.
• creates enact_candidate_weight, which gives us the worst case weight which we can then use prior to calling enter.

cc @pepyakin

Notes for reviewers:

• for people familiar with the FRAME storage apis: please focus on making sure the hardcoded storage read / write numbers look correct
• for people familiar with the parachains runtime: please focus on making sure the way the weights from enact_candidate are used is correct

relates to paritytech/polkadot#4044

skip check-dependent-cumulus

[emostov]

cc @drahnr @Lldenaurois this is the PR I was discussing yesterday that addressed that stray TODO

[emostov]

615e788 adds some checks to bitfield_count_ones to try and minimize the amount of bogus bitfields that end up affecting weight.

14faefb tries to optimize counting the votes in bitfields by tracking them in sanitize_bitfields (after the checks are passed). This change lets us avoid calling bitfield_count_ones in create_inherent. However we still need to call bitfield_count_ones in the weight annotation for enter and when doing initial weight limiting in enter because we do not want to check signatures in the runtime when we do not yet know if the input could be overweight

[emostov]

@drahnr Can this be closed?

[drahnr]

I think it's still desirable to account for the enacted candidates, but it depends how much work that'd entail to update vs reimpl?