[Feature] - Generate Bug Report's System Information within BambooTracker

[OPNA2608]

Checklist

• I'm requesting exactly 1 feature with this issue.
• This feature hasn't already been requested.
• This feature hasn't already been implemented in the latest development build.

---

Requested Feature

Instead of tasking users with explaining their OS, BT version & build type, maybe we should offer a "Build information" section in some help dialogue and tell users to copy-paste / screenshot that instead.

• I'm sure "Operating System" could be described at runtime via some mechanisms, either in some portable manner or #ifdefing platform-specific detection techniques
• "Build Type" is easily doable via new config flags (to tell apart an actual vX.Y.Z release build from a CONFIG+=release-optimised build). this could however be abused to label an unofficial build as a seemingly official one, so another factor like code signing or releasing hashes of the download archives would be needed to ensure legitimacy.
  flag examples:
  • no flag - Manually-built (reasonable default I think)
  • CONFIG+=buildtype_official - Official (we set this on release & dev builds and document it as a flag used internally for identifying a build released by us, hoping that users & packagers understand not to abuse this)
  • CONFIG+=buildtype_package - System Package (for package managers to set, this can clue us in that something might be wrong with the package, if package managers are willing to cooperate and enable this flag in their builds)
  • both flags -> Configuration error (might help packagers who just skim the available options and enable everything)
• "BambooTracker Version" is gonna be abit tricky:
  • We can use version.hpp to get the last release version but that's not super useful with our current version.hpp update workflow.
    sidenote, maybe we should update the version to vX.Y.Z-pre after every release (X.Y.Z being the next planned version) and change it to just vX.Y.Z on a release. though even then, it would just be an indicator for non-release builds and useless for pinpointing an exact commit for debugging purposes
  • We can't rely on git information to get the actual git commit because the .git directory with all the git commit information isn't guaranteed to exist (for example in build environments that throw away .git for reproducibility reasons)