This reverts commit f75bb76.

This reverts commit 0fe3926.

# Incremental Graph-Copy-Based Upgrades

Refinement of #4286

Supporting arbitrarily large graph-copy-based upgrades beyond the instruction limit:
* Splitting the stabilization/destabilization in multiple asynchronous messages.
* Limiting the stabilization work units to fit the update or upgrade messages.
* Blocking other messages during the explicit incremental stabilization.
* Restricting the upgrade functionality to the canister owner and controllers.
* Stopping the GC during the explicit incremental upgrade process.

## Usage

For large upgrades:
1. Initiate the explicit stabilization before the upgrade:
    
```
dfx canister call CANISTER_ID __motoko_stabilize_before_upgrade "()"
```

* An assertion first checks that the caller is the canister owner or a canister controller.
* All other messages to the canister will be blocked until the upgrade has been successfully completed.
* The GC is stopped.
* If defined, the actor's pre-upgrade function is called before the explicit stabilization.
* The stabilzation runs in possibly multiple asynchronous messages, each with a limited number of instructions.

2. Run the actual upgrade:

```
dfx deploy CANISTER_ID
```

* Run and complete the stabilization if not yet done in advance. 
* Perform the actual upgrade of the canister on the IC.
* Start the destabilization with a limited number of steps to fit into the upgrade message.
* If destabilization cannot be completed, the canister does not start the GC and does not accept messages except step 3.

3. Complete the explicit destabilization after the upgrade:

```
dfx canister call CANISTER_ID __motoko_destabilze_after_upgrade "()"
```

* An assertion checks that the caller is the canister owner or a canister controller.
* All other messages remain blocked until the successful completion of the destabilization.
* The destabilzation runs in possibly multiple asynchronous messages, each with a limited number of instructions.
* If defined, the actor's post-upgrade function is called at the end of the explicit destabilization.
* The GC is restarted.

## Remarks

* Steps 1 (explicit stabilization) and/or 2 (explicit destabilization) may not be needed if the corresponding operation fits into the upgrade message.
* Stabilization and destabilization steps are limited to the increment limits:

    Operation | Message Type | IC Instruction Limit | **Increment Limit**
    ----------|--------------|----------------------|--------------------
    **Explicit (de)stabilization step** | Update | 20e9 | **16e9**
    **Actual upgrade** | Upgrade | 200e9 | **160e9**

* The stabilization code in the RTS has been restructured to be less monolithic.

…4410)

Only passive Wasm data segments are used by the compiler and runtime system. In contrast to ordinary active data segments, passive segments can be explicitly loaded to a dynamic address.

This simplifies two aspects: 
* The generated Motoko code can contain arbitrarily large data segments which can loaded to dynamic heap when needed.
* The IC can simply retain the main memory on an upgrade without needing to patch the active data segments of the new program version to the persistent memory.

However, more specific handling is required for the Rust-implemented runtime system:
The Rust-generated active data segments of the runtime system is changed to passive and loaded to the expected static address at the program start (canister initialization and upgrade).
The location and size of the RTS data segments is therefore limited to a defined reserve, see above. 
This is acceptable because the RTS only uses small size for data segments (e.g. 54KB) that is independent of the compiled Motoko program.

…4411)

Only passive Wasm data segments are used by the compiler and runtime system. In contrast to ordinary active data segments, passive segments can be explicitly loaded to a dynamic address.

This simplifies two aspects: 
* The generated Motoko code can contain arbitrarily large data segments which can loaded to dynamic heap when needed.
* The IC can simply retain the main memory on an upgrade without needing to patch the active data segments of the new program version to the persistent memory.

However, more specific handling is required for the Rust-implemented runtime system:
The Rust-generated active data segments of the runtime system is changed to passive and loaded to the expected static address at the program start (canister initialization and upgrade).
The location and size of the RTS data segments is therefore limited to a defined reserve, see above. 
This is acceptable because the RTS only uses a small sized data segment that is independent of the compiled Motoko program.

…(32-Bit) (#4383)

Preparing merging #4369 in #4193

…(64-Bit) (#4392)

Preparing merging #4369 in #4225

)

* Object pooling

* Update benchmark results

* Optimize further (BigNum pooling)

* Update benchmark results

* Adjust tests

* Optimize static blobs

* Adjust test and benchmark results

* Update documentation

* Object pooling

* Update benchmark results

* Optimize further (BigNum pooling)

* Update benchmark results

* Adjust tests

* Optimize static blobs

* Adjust test and benchmark results

* Update documentation

* Manual merge conflict resolution