Clarification of MI_OVERRIDE and mimalloc-new-delete.h

Does `MI_OVERRIDE=ON` cmake option imply that new/delete are overridden in addition to the C malloc/etc interface?

If I compile with `MI_OVERRIDE` on Linux, I get "multiple definition" linker errors when I try to `#include `

Here are the messages from `gcc-10`:
```
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `operator new(unsigned long, std::nothrow_t const&)':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc-override.c:190: multiple definition of `operator new(unsigned long, std::nothrow_t const&)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:31: first defined here
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `operator new[](unsigned long, std::nothrow_t const&)':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc-override.c:191: multiple definition of `operator new[](unsigned long, std::nothrow_t const&)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:32: first defined here
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `mi_free':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc.c:481: multiple definition of `operator delete[](void*)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:26: first defined here
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `mi_free':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc.c:481: multiple definition of `operator delete(void*)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:25: first defined here
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `mi_free_size':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc.c:576: multiple definition of `operator delete[](void*, unsigned long)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:36: first defined here
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `mi_free_size':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc.c:576: multiple definition of `operator delete(void*, unsigned long)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:35: first defined here
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `mi_new':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc.c:857: multiple definition of `operator new[](unsigned long)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:29: first defined here
/usr/bin/ld: submodules/mimalloc/libmimalloc-debug.a(alloc.c.o): in function `mi_new':
/home/hans/openscad_malloc/submodules/mimalloc/src/alloc.c:857: multiple definition of `operator new(unsigned long)'; CMakeFiles/OpenSCAD.dir/src/openscad.cc.o:/home/hans/openscad_malloc/submodules/mimalloc/include/mimalloc-new-delete.h:28: first defined here
```
(I got even stranger messages if I tried to build with `clang-14`, where it claimed they were redefined in `boost/system/detail/std_interoperability.hpp` which I assume was some kind of compiler bug since I saw no such definitions in that file)

Is the answer specific to target OS? (i.e. `MI_OVERRIDE` implies new/delete override, everywhere *EXCEPT* on Windows?)
I'm wondering about this since `MI_OVERRIDE` defaults ON, and I see this preprocessor conditional in the tests:
https://github.com/microsoft/mimalloc/blob/38a03229c89afbf2722e48c63da696bf11589dee/test/main-override.cpp#L17-L19

Read the MI_OVERRIDE CMake option, src/alloc-override.c, include/mimalloc-new-delete.h, and test/main-override.cpp. Reproduce the Linux linker errors with MI_OVERRIDE enabled and the header included, then determine whether the interaction is platform-specific. Done means the behavior and supported configuration are clearly documented, with the conflicting setup explained.

Written by the indexing model from the issue text.