Support loading relocatable Mach-O objects (MH_OBJECT)

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

This is a feature request, filed because the error text asks for one.

## What CLE does now

`MachO.__init__` accepts `MH_EXECUTE` and `MH_DYLIB` and refuses everything else:

```python
raise CLECompatibilityError(
f"Unsupported Mach-O file type: {MachoFiletype(self.filetype)}. "
"Please open an issue if you need support for this"
)
```

`MH_OBJECT` (file type 1) is a relocatable Mach-O — the `.o` a compiler emits, and what a
`.a` archive member is. CLE loads the ELF equivalent (`ET_REL`) and the COFF equivalent, so
this is the one relocatable container it does not.

## Scale

In a corpus-wide CFG sweep over 77,187 failing units, `MH_OBJECT` is 3,376 of them:

| architecture | container | count |
| --- | --- | --- |
| aarch64 | mach-o | 1711 |
| x86_64 | mach-o | 1444 |
| x86 | mach-o | 175 |
| arm | mach-o | 46 |

Example object: aarch64 Mach-O, sha256
`06fb96b43178349b1afdeebbf92e3f90ae9f91061beccbefb92b55238b027cf2`. Any `cc -c` output on
macOS is one:

```shell
printf 'int f(int x) { return x + 1; }\n' > t.c
cc -c -o t.o t.c
python -c "import cle; cle.Loader('t.o')"
```

## What it would take

`MH_OBJECT` has no `__PAGEZERO`, its segment has a zero `vmaddr`, and its sections are
placed by the linker rather than by the file, so it needs per-section mapping and
relocation processing the way `ET_REL` does, rather than the segment mapping the current
backend uses. Its symbol table is `LC_SYMTAB` only — there is no `LC_DYSYMTAB` binding
information to apply.

The same corpus run also shows the neighbouring types, for whatever it is worth in
prioritising: `MH_BUNDLE` 2957 and `MH_KEXT_BUNDLE` 113, both of which
https://github.com/angr/cle/pull/728 loads, and `MH_DSYM` 19, which that pull request
refuses with a specific message because a dSYM companion carries debug information and no
loadable image.