[lldb] ObjectFileELF uuid is derived from .gnu_debuglink section in a way that does not change between builds

At least, that's how it appears. When linking with lld/mold, my executables get a .gnu_debuglink section that looks like this:
```
String dump of section '.gnu_debuglink':
[ 0] Scrt1.o.debug
[ 12] %Tcrti.o.debug
[ 24] y�v�crtbeginS.o.debug
[ 40] crtendS.o.debug
[ 50] A6^P�crtn.o.debug
[ 66] h1
```
Which looks quite messed up, but is very similar to the gnu_debuglink mentioned at the very end of [this bugzilla issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1485556). This section is the same for every build.

As a last resort it looks llike `ObjectFileELF::GetUUID` tries to generate its uuid from a crc of this section:
https://github.com/llvm/llvm-project/blob/ec1bf9c56250803b434220d24d5035c121de72fa/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L903-L908

While debugging my project, if I rebuild the executable after having initially loaded it into lldb, further runs will show wildly incorrect source locations and to fix the issue I usually just restart lldb. After finding this, though, I added `-Wl,--build-id=md5` to my link commands which seemed to workaround the issue.

Not sure if this is just an issue with how I build my projects, and this was on a somewhat outdated fork of lldb, though the code embedded looks mostly the same (`m_data` has just been made into some fancy pointer type). Once lldb rebuilds I will confirm if this is still an issue on latest.

Start in lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp at ObjectFileELF::GetUUID, especially the cited lines that derive the UUID from .gnu_debuglink. Reproduce with executables linked by lld or mold, rebuild them, and compare UUIDs and reported source locations; also compare the behavior when using --build-id=md5. Done means the current behavior is confirmed and the UUID handling no longer causes stale or incorrect locations.

Written by the indexing model from the issue text.