bug#49271: 28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location

[Eli Zaretskii]

> From: Jim Myhrberg <contact@jimeh.me>
> Date: Wed, 30 Jun 2021 11:04:43 +0100
> 
> I've just tried "Contents/lib", and it allowed me to sign and notarize
> the .app bundle. And combined with your patch from bug#49270, all
> bundled *.eln files are also correctly located and loaded :)
> 
> I did a bit of searching myself for alternatives and found
> "Contents/PlugIns" as a potentially suitable place, but a quick test
> revealed codesign fails the same way with it as it does with
> Contents/MacOS.
> 
> Personally I think Contents/lib is probably fine, as both codesign and
> Apple's notarization process are happy with it. And the notarization
> process seems very picky. For example, when *.eln files were in
> Resources/native-lisp, my initial notarization attempts failed because
> it considered the *.eln files to be binaries, and they had not been
> signed by codesign despite the --deep flag being used. Hence I'm
> individually signing all the *.eln files before signing the app bundle
> itself to get the app through notarization.

The *.eln files are shared libraries.  What is the canonical place to
install shared libraries specific to an application?