[GR-41196] Provide .debug.* sections that contain build options and properties used in the build of an image.

[graalvmbot]

This PR will make native-image embed .debug.svm.imagebuild.* sections into an image when building with -g. This can be used to find out what options and other settings were used to build that image.

For example building native-image -Dmy.system.property=123 HelloJava -O0 -g results in an executable hellojava where the following can be used:

$ readelf -p .debug.svm.imagebuild.classpath hellojava

String dump of section '.debug.svm.imagebuild.classpath':
  [     0]  /home/pwoegere/test

$ readelf -p .debug.svm.imagebuild.arguments hellojava

String dump of section '.debug.svm.imagebuild.arguments':
  ...
  [    b1]  -H:Path=/home/pwoegere/test
  [    cd]  -H:Optimize=0
  [    db]  -H:GenerateDebugInfo=2
  [    f2]  -H:Class@explicit main-class=HelloJava
  [   119]  -H:Name@main-class lower case as image name=hellojava
  ...

$ readelf -p .debug.svm.imagebuild.java.properties  hellojava

String dump of section '.debug.svm.imagebuild.java.properties':
...
  [   1a7]  -Dmy.system.property=123
... 

[olpaw]

This PR implements #5010

[adinn]

This looks fine Paul and thanks for reorganizing the provider code so it is managed by the feature. Much neater.

[zakkak]

LTGM as well. Thanks @olpaw

[zakkak]

Is the use of var encouraged in the GraalVM code base?
If so, I will need to keep that in mind :)

(I am personally not a fan, but that's just my personal taste)

[olpaw]

Yes, if it's easy from the context to guess what type the local is or the types are rather trivial, it's fine to use var.
If the type is non-trivial and being explicit actually helps to understand the code better then not using var is recommended.