feat: Implement DTS for replicated queries

[dsarlis]

This PR introduces Deterministic Time slicing for replicated queries. The total limit for replicated queries remains the same but the execution can be "sliced" over multiple rounds allowing for more stable finalization rate.

The change seems big but can be broken down to the following main points:

• Observe that handling the DTS of a replicated query is quite similar to the existing handling of update calls and tasks (like heartbeat and timers).
• Re-purpose the "update" DTS handler to "call_or_task" DTS handler. Its job would be to cover calls to canister methods, either update or query and canister tasks (all of which happen in replicated mode).
• Extend the CanisterCallOrTask enum to capture both calls to update and query methods (instead of of only update methods).
• Using the above enum we can handle the differences between the different messages. These are mainly in, (i) constructing the correct system API based on the type of call, (ii) constructing the DTS helper and performing the initial validation and finally, (iii) applying the state changes after execution is over (queries persist only part of the state). These changes can be found in the (renamed) call_or_task.rs file.
• Add a similar test suite for replicated queries dealing with DTS edge cases by extending the existing tests for update methods. The idea is to add a helper that accepts the method name and executes the same test by calling the respective method. Some are "copied" because they have to use different approach (depending on what system API calls are available in update vs query methods).
• Finally remove replicated_query.rs as it's no longer needed.