Update the active_ranges in the DeciderProvingKey construction to avoid the two falling out of sync

[maramihali]

One situation in which this could happen is if we change where the lookup and databus table data are stored in the execution trace.

[maramihali]

This had to do with finding a way to avoid inconsistencies between how active ranges are constructed and updated in the execution trace tracker, given a set of DeciderProvingKey, potentially overflowing. More precisely, if one decides to change, say, where the lookup table data is stored, they will also have to potentially change something in the update() function in the tracker. It would be nice if this was obvious rather than discovered after debugging why your client ivc proof is failing.