perf: compile the reference-counted deletion machinery with mimalloc

This PR moves big-object allocation and the reference-counted deletion machinery into the translation unit that compiles mimalloc, so that mimalloc's fast paths inline into them, worth 0.2% to 0.4% of user instructions on elaboration.

`lean_free_object`, `lean_alloc_object` and the `lean_del_core` deletion loop move from `object.cpp` to a new `object_rc.cpp`, which `mimalloc.cpp` includes rather than compiling on its own; without mimalloc it is built as an ordinary translation unit. `lean_dealloc` moves to `object.h` so both see it, and `deactivate_task` and `deactivate_promise` lose their internal linkage, as `object_rc.cpp` now calls them across translation units.

The visible effect is on `lean_free_object`, whose per-kind `mi_free_size` calls collapse once mimalloc's definitions are in scope, since `mi_free_size` is `mi_free` in a release build:

```diff
-mov    eax, [rdi+0x4]                  ; six-way switch on the object kind,
-shr    ecx, 0x18                       ; each arm computing a byte size for
-cmp    ecx, 0x5                        ; mi_free_size
-ja     <mi_free>
-jmp    rcx                             ; jump table
+movzx  eax, BYTE PTR [rdi+0x7]         ; only MPZ still needs its destructor
+cmp    eax, 0xfa000000
+jne    <mi_free>
```

Measured by swapping `libleanshared.so` between two full builds, single-threaded with `-DElab.async=false` on a pinned core with ASLR disabled: `tests/elab_bench/big_omega.lean` 18.7812G to 18.7407G user instructions (-0.215%), `import Lean` 1.93569G to 1.92795G (-0.400%).

The compiled benchmarks that stress constructor churn are unaffected, at 0.000% on `rbmap`, `rbmap_fbip`, `hashmap` and `unionfind`. Their hot deletion path is `lean_free_small_object`, which is `static inline` in `lean.h` and so already inlines `mi_free` into compiled code; what this PR reaches is the runtime's own C++ paths for arrays, strings, closures and big objects, which elaboration exercises and those benchmarks do not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>