fix(autopack): ensure shared library with interpret section is detected as AutopackKind::SharedLibrary

[jaudiger]

This bug has been detected with brioche-dev/brioche-packages#3705.

Some shared libraries embed a .interp section so they can be executed directly as standalone binaries (for example ./libcap.so --summary prints version info). The autopack classifier checked for an interpreter before checking is_lib flag, so such
libraries were classified as DynamicBinary. The DynamicBinary packing path replaces the entire file with a copy of the brioche-packed runner (an ET_EXEC executable), destroying the original ET_DYN shared library on disk. It has two consequences with this classification:

1. Build failures within the same recipe: any subsequent linker invocation in the same build step that tried to link against the packed .so would fail with ld.gold: error: unsupported ELF file type 2, because ld.gold refuses to use an ET_EXEC file as a shared library input which is correct.
2. Broken downstream consumers: packages depending on the affected library and linking against it at build time would hit the same ET_EXEC rejection from the linker.

This bug was hidden and only exposed by the gitCheckout change that strips .git directories by default. The libcap Makefile uses a .git presence check to decide how programs are linked:

DYNAMIC := $(shell if [ ! -d "$(topdir)/.git" ]; then echo $(SHARED); else echo no ; fi)

With .git present (current behavior), DYNAMIC=no and programs linked statically against libcap.a, never touching the packed .so. With .git removed (PR brioche-dev/brioche-packages#3705), DYNAMIC=yes and programs tried to link dynamically against libcap.so, which had been silently replaced by the ET_EXEC packed runner.

This PR just inverts the two if statements detecting the AutopackKind.