refactor: Consolidate how system state modifications are extracted from the System API

[dsarlis]

Currently, there are two similar functions in the SystemApiImpl to extract system state modifications. One of them take_system_state_modifications is used in the sandbox when preparing the state changes to be transmitted back to the replica. Then, the replica after deserializing the result that it receives from the sandbox calls into_system_state_changes on the reconstructed system_api to extract the changes again.

In a recent PR, into_system_state_modifications was changed (to make it more clear which changes are relevant per message type) but take_system_state_modifications wasn't. This works correctly because into_system_state_modifications is the last one that's called before applying the state changes back to the canister state. However, it's also a very clear example of how the code can easily diverge and go unnoticed, potentially with more severe implications in the future.

This PR proposes to use one function which seems to provide the usual benefits of consistent way of applying the changes and "having one way" of doing the same task. We keep take_system_state_modifications (this allows us to get rid of some clones but more importantly it's needed in the sandbox, see comment in the existing code) and change the call sites respectively.