`multiprocessing.shared_memory.SharedMemory` currently tries to unlink a POSIX
shared memory object if it fails to `mmap` it after opening/creating it.

However, since it only catches `OSError`, it fails to do so when opening an
existing zero-length shared memory object, as `mmap.mmap` raises a `ValueError`
when given a 0 size.

Fix this by catching all exceptions with a bare `except`, so the cleanup is run
for all errors.

… handling

`multiprocessing.shared_memory.SharedMemory` currently tries to unlink a POSIX
shared memory object if it fails to mmap it after opening/creating it in the
constructor. It does this by calling `cleanup()`, which unregisters the shared
memory despite it not having been registered. This will trigger a separate
exception in the resource tracker.

Fix this by calling the low-level unlink directly.

`multiprocessing.shared_memory.SharedMemory` currently attempts to `unlink` a
POSIX shared memory object it has opened or created if a subsequent exception
is raised in its constructor.

This is necessary to avoid it leaking if the shared memory object was created
in the constructor, however it seems inappropriate if it is opening a
pre-existing shared memory object.

Fix this by only unlinking the shared memory object if it was created.

These are allowed by POSIX and it seems more consistent/cleaner to support them
than forcing the user to treat them as a special case.

Windows does not support creating a zero-length mapping, and neither does
`mmap` on any platform, so skip those operations and assign a zero-length
buffer instead.

TODO: The way the POSIX/Windows code is interleaved inside if statements makes
for difficult to follow and deeply nested logic. It might be better to refactor
this code and keep the platform-specific logic in separate functions or
possibly even implementation classes.

It appears MacOS has tight limits on name length which the new tests were
exceeding.