feat: not inclusive start block

[invocamanman]

Description

We use the start_block as the first block that's proved. That would mean that the block proven follows the [start_block, finalBlock] convention.

Usually in rollups is used the (start_block, finalBlock] convention, so, start block not inclusive.
This is useful usually to check that the last finalBlock matches the start_block of the next proving block.

As an example of our current and new approach given a scenario with 2 range proofs. The first proof proves the block 1 and 2 and the second one proves the block 3:

Current Approach

Proof	start_block	end_block
Proof 1	1	2
Proof 2	3	3

---

New Convention

Proof	start_block	end_block
Proof 1	0	2
Proof 2	2	3

Additions and Changes

I fix a condition and add comments regarding this change
Mainly i think this will be relevant in the upcoming PRs.

For example now instead of doing this kinda minus one scenarios we will be able to use start_block right away

It's similar to the common convention with the rollups and personally i find it more intuitive ( maybe bc i work on a rollup for a while :P)

PR Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added or updated tests that comprehensively prove my change is effective or that my feature works

[atanmarko]

@invocamanman I find this very confusing.
It makes more sense that start_block..end_block gets into the proof (inclusive).

EDIT - if this is how other count proof ranges, then ok.

[iljakuklic]

Wondering why was this convention introduced, as it's quite different from the usual [start, end) convention which may cause unintended off-by-one errors.

[Freyskeyd]

How does it integrate with the aggsender ? cc @arnaubennassar
And what's about the fer-proposer ? cc @vcastellm