This commit adds code in the post-prime callback to handle the specific
combination of "ubuntu@24.04" base + "python" plugin. The handling detects
and removes a primed "lib64" symlink to "lib", which can't stay because
it breaks the "lib64" symlink to "usr/lib64" on the base layer, making the
rock unusable.

Read on for more context on *why* this started happening now:

The Python plugin works by creating a virtual environment on the part's
install dir (which eventually gets primed). By default, the creation of
the virtual environment will setup a directory structure like this:

```
<install-dir>
     |- bin/
     |- lib/
     |- ...
     |- lib64 -> lib
```

That is, the creation itself places a "lib64" symlink pointing to "lib".
If this gets primed as-is, this symlink will override the base layer's
own symlink of "lib64" to "usr/lib64", which renders the rock unusable
because all binaries expect the loader to exist in "lib64/ld-linux-x86-64.so.2",
when the loader's "true" location is in "usr/lib64/ld-linux-x86-64.so.2".

This wasn't an issue prior to 24.04 because of the way we extract stage
packages: since the base layer doesn't include the Python interpreter,
rockcraft projects need to provision Python themselves, typically via
the "python3-venv" stage-package. This causes the inclusion of the package's
dependencies, ultimately pulling in "libc6".

On Ubuntu versions older than 24.04, the "lib64" package includes the
"ld-linux-x86-64.so.2" loader as "/lib64/ld-linux-x86-64.so.2". This means that
by the time the virtual environment creation starts the install dir already
has a "lib64" directory, which I guess the venv just accepts and leaves alone.
The end result is that "lib64" is not a symlink to "lib", and the usrmerge
handling code that we already have when packing takes care of packing the
files in "lib64" as inside "usr/lib64". The install dir looks like this:

```
<install-dir>
     |- bin/
     |- lib/
     |- ...
     |- lib64/
          |- ld-linux-x86-64.so.2
```

However, 24.04 changed the usrmerge handling and now the libc6 package includes
that loader as "/usr/lib64/ld-linux-x86-64.so.2", which means that the "lib64"
directory doesn't exist anymore when the venv is created. Thus, "lib64" is
created as a symlink to "lib" and breaks the base layer:

```
<install-dir>
     |- bin/
     |- lib/
     |- ...
     |- lib64 -> lib
     |- usr
          |- lib64
               |- ld-linux-x86-64.so.2
```