Consider bundles for scheduler processor run [prototype]

[facuMH]

This PR considers processed bundles in the scheduler processor run, when checking whether a transaction could be processed or not. Without this check no bundle would ever be considered for a proposal in single proposer mode.

Bundle integration tests are modified to run once with single block proposal and once with distributed block proposal.

Note for reviewers:
Each commit in the current iteration has been refactored to be conceptually unitary:

• Add bundle tracker to scheduler processor.

• Handle bundles in scheduler processor.

• Update mocks.

• Adapt existing unit tests.

• Add processor bundle unit tests.

• Run bundle integration tests with single proposer mode.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
gossip/emitter/proposals.go	100.00% <100.00%> (ø)
gossip/emitter/scheduler/processor.go	100.00% <100.00%> (ø)
gossip/emitter/scheduler/scheduler.go	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[HerbertJordan]

The modification looks concise and at the right point, but one or two additional edge cases need to be considered. Please have a look.

About the testing: I think it is sufficient to have one dedicated test for running bundles in single-proposer mode or a few selected for which the block-formation mode is relevant. No need to run all tests in both modes.

[LuisPH3]

I lack of context here, I do not know if this is documented somewhere else:
what is the boolean value, and how does it relate to bundles?
It returns true if any transaction is not skipped? But a bundle which yields no transactions is not skipped?
I am quite confused about how to define the expectations of these functions. This prevents me from providing a good review for the testing.

[facuMH]

documentation added in 1b83457. Hopefully this can help you better judge the intentions.