Eclipse Temurin uses "incorrect" `java.library.path` on Debian/Ubuntu

## Summary

Eclipse Temurin uses "incorrect" `java.library.path` on Debian/Ubuntu

## Steps to reproduce

```
$ apt-get install temurin-8-jdk
$ /usr/lib/jvm/temurin-8-jdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10
```

## Expected results

`java.library.path` having the same value as on Debian/Ubuntu-provided packages. The `/usr/lib/x86_64-linux-gnu` directory is of particular importance to our use case (more about it later in this issue).

### Ubuntu 18.04

```
# /usr/lib/jvm/java-8-openjdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10
java.library.path = /usr/java/packages/lib/amd64
/usr/lib/x86_64-linux-gnu/jni
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/jni
/lib
/usr/lib
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
```

### Debian `stretch`

(Cannot run this test on my `bullseye` system since JDK 8 is no longer available in Debian since a few years ago.)

```
root@4691e42881b9:/# /usr/lib/jvm/java-8-openjdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10
java.library.path = /usr/java/packages/lib/amd64
/usr/lib/x86_64-linux-gnu/jni
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/jni
/lib
/usr/lib
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 1.8.0_322-8u322-b06-1~deb9u1-b06
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
```

## Actual results

```
$ /usr/lib/jvm/temurin-8-jdk-amd64/bin/java -XshowSettings:properties -version 2>&1 | grep java.library.path -A10
java.library.path = /usr/java/packages/lib/amd64
/usr/lib64
/lib64
/lib
/usr/lib
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 1.8.0_322-b06
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 1.8
java.vendor = Temurin
```

## Triaging info

**Java version:**

```
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
```

**What is your operating system and platform?**

Debian GNU/Linux 11 (bullseye) on x86-64.

**How did you install Java?**

`apt-get install temurin-8-jdk`

**Did it work before?**

Probably not. The older package `adoptopenjdk-8-hotspot` version `8u292-b10-3` has the exact same characteristics on Ubuntu 18.04.

**Did you test with other Java versions?**

Yes, see above. Package-provided JDKs both on Debian bullseye and Ubuntu 18.04 are tested to have the "correct" setting.

## More details/the bigger picture

I deliberately wrote "incorrect" in quotes here since it can be argued whether the Eclipse Temurin semantics are "correct" or not in this case. Temurin just uses the OpenJDK-provided defaults as-is, AFAIK. The way Debian and Ubuntu does it is by patching the HotSpot `DEFAULT_LIBPATH` as can be seen in this diff: https://salsa.debian.org/java-team/openjdk-8/-/blob/master/debian/patches/hotspot-libpath-default.diff

So, why is this a problem for me/us? What we are doing is running Tomcat (with distro-provided packages from Ubuntu) on Eclipse Temurin. _However_, I recently noticed that Tomcat fails to pick up the "Tomcat native" libraries. Here's the content of the `libtcnative-1` package on Ubuntu 18.04:

```
$ dpkg -L libtcnative-1
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libtcnative-1.a
/usr/lib/x86_64-linux-gnu/libtcnative-1.so.0.2.21
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/tcnative-1.pc
/usr/share
/usr/share/doc
/usr/share/doc/libtcnative-1
/usr/share/doc/libtcnative-1/README.Debian
/usr/share/doc/libtcnative-1/changelog.Debian.gz
/usr/share/doc/libtcnative-1/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/libtcnative-1
/usr/lib/x86_64-linux-gnu/libtcnative-1.so
/usr/lib/x86_64-linux-gnu/libtcnative-1.so.0
```

So, in other words: the Debian and Ubuntu distributions are built using the presumption that Java native libraries being loaded via JNI can be present in `/usr/lib/x86_64-linux-gnu`. As far as I know, the reason for this is to be able to support [multiarch](https://wiki.debian.org/Multiarch), i.e. libraries for multiple architectures to be _present at the same time_ on the system. That's why these files are not just put in `/usr/lib` as usual.

## Workaround

We can override `-Djava.library.path` in e.g. `/etc/default/tomcat8`, it will be picked up by the JDK. However, I still think it's worth bringing this up for discussion. There's obviously a balance between "stay close to the spirit of the upstream" vs "make it work well with the distro ecosystem at large" here, and there are perhaps other factors as well to weigh in that I'm not aware of at the moment.

Finally, thanks for a great JDK distribution! :pray:

Start with the reported `java -XshowSettings:properties -version` command and compare Temurin's `java.library.path` with the Debian patch `hotspot-libpath-default.diff`. Review the Tomcat native library example and the proposed `-Djava.library.path` workaround; done would require an agreed decision on the expected Debian/Ubuntu behavior and a clearly scoped change.

Written by the indexing model from the issue text.