Sync with upstream script to properly handle symlinks (#27)

I ran a comparison of the chromium's sysroots with ours and found out,
that symlinks look differently, e.g.
- chromium: `libutil.so -> ../../..//lib/x86_64-linux-gnu/libutil.so.1`
- ours (before this change): `libutil.so ->
/lib/x86_64-linux-gnu/libutil.so.1`

This might have worked in the past with Bazel 7, but with Bazel 8 in
some situations (maybe due to Bazel 8's stricter sandboxing) it just
fails. I was not able to reproduce it locally, it only happens in CI
with enabled Bazel Cache.

This change enables the relative symlink handling instead of using
absolute paths and syncs with the upstream script of the chromium
project.

(`lapack` and `blas` seem to be in the correct shape: `liblapack.a ->
./lapack/liblapack.a`)

Tested in swift-nav/rules_swiftnav#200 (see
testplan in PR description)

sysroot: fix missing symlinks for blas and lapack [IO-60] (#25)

To support cross-compiling from x86_64 to aarch64 debian targets - we're
using some scripts from the chromium
project for building sysroots directly from debian (`.deb`) packages.

A caveat of using these scripts is they rely on very low level plumbing
commands (i.e. `dpkg-deb`) to handle unpacking
and installing the package contents (libs and headers), into "jail" (the
sysroot).

These commands don't handle many details of the full install process. In
the case of blas and lapack - they don't handle the post install step of
creating symlinks at `/usr/lib/${TRIPLE}/libblas.so`. This is important
because this location is on the linkers default search path. The reason
these symlinks are not part of the package by default is because blas
and lapack are virtual packages, there are several different "concrete"
packages that can satisfy the dependency (i.e. `libblas-dev`,
`libopenblas-dev`, etc..). It's up the the debian alternatives system (&
system administrators) to handle the detail of which concrete library
the `libblas` and `liblapack` symlinks actually point to.

I explored a couple of routes to try to do this in a less janky way then
manually creating the links, but this ended up being a rabbit hole.
Ideally we revisit the way we're building these sysroots in a more
robust way.

In the meantime we can now remove the hardcoded linker paths in
libraries that depend on `blas` and `lapack`:

https://github.com/swift-nav/rules_swiftnav/blob/d10814e9b8f3d3b948e3ea9c1aed9c80c2fd74cc/third_party/suitesparse.BUILD#L25.
Trying to handle all the different conditions (os, arch, sysroot or no
sysroot, etc..) was becoming untenable, and just didn't work at all in
some cases.

## Testing

I've tested the resulting sysroot build locally to verify that this
mechanism of creating the links works.

add testing infra to sysroot creation (#23)

Adds a test harness to help validate sysroot changes before publishing
releases.

---------

Co-authored-by: Matt Peddie <matt.peddie@swift-nav.com>

Add blas and lapack to sysroot

add testing infra to sysroot creation (#23)

Adds a test harness to help validate sysroot changes before publishing
releases.

---------

Co-authored-by: Matt Peddie <matt.peddie@swift-nav.com>

Fix debian bullseye x86_64 sysroot [CLARM-39] (#20)

The fix makes the script retry 4 times if the checksum of the
downloaded package is wrong. The issue is caused by a server
that sometimes breaks the connection without delivering all the data.
curl: (18) transfer closed with 8605775 bytes remaining to read

Fix debian bullseye x86_64 sysroot [CLARM-39] (#20)

The fix makes the script retry 4 times if the checksum of the
downloaded package is wrong. The issue is caused by a server
that sometimes breaks the connection without delivering all the data.
curl: (18) transfer closed with 8605775 bytes remaining to read

Add debian bullseye aarch64 sysroot [CLARM-13] (#18)

* Aarch sysroot [CLARM-13]

* Add arch

* Fix

* Add sysroot-creator.sh script

* Fix

* Rename

* Rename

* Rename

sha

add release