Versioning - Include more details about the originating changeset

Keen on having access to the following items as part of build scripts from e.g. GitVersion:

Branch name
- Modify build logic based on prefixes/particular branch names. Example - for PR builds would be doing linting early, creating more simplified/summarised change documentation / checking docs present, skipping full doc autobuild/integration testing and doing it as a separate step as part of CI process.
- Enable as parameter in scripting, to build files to change appearances of things (e.g. adding version numbers to dev builds, warning colours), include unminified versions of JS as part of packaging, that sort of thing
- Bundled to use later in deployment scripts

Commit Hash (SHA)
- Bundling artifacts - deliverables, logs etc based on this to archive
- "Double check" for matching with an actual SCM change

Commit Date
- More user friendly "hash" for e.g. testers, added to autogenerated change list documentation

Usually have all these items in a simple JSON file bundled with each release, regardless of which versioning scheme I'm using for a particular project, to ensure I can trace the provenance for a particular package/release/deployment etc.

Could be achieved by adding to e.g.
https://github.com/cake-contrib/Cake.Recipe/blob/08ca8d06ae0b7d25a94780f1424e966fd9d2348e/Cake.Recipe/Content/gitversion.cake#L10

But may be muddying purpose of that class/method.

Start by reading Cake.Recipe/Content/gitversion.cake around the referenced line. Compare how branch name, commit SHA, and commit date could be exposed to build scripts and bundled as release provenance, while resolving whether this belongs in that file or another component. Done means the intended metadata is available to the stated build and deployment workflows.

Written by the indexing model from the issue text.