CLI: New dotenv output format

[arturcic]

Discussed in https://github.com/GitTools/GitVersion/discussions/4173

^{Originally posted by **cimnine** August 21, 2024} I would appreciate it if the GitVersion CLI could output all the variables in `dotenv` format: ```sh $ dotnet gitversion -output dotenv AssemblySemFileVer=1.0.1.0 AssemblySemVer=1.0.1.0 BranchName=main BuildMetaData= CommitDate=2024-08-21 CommitsSinceVersionSource=0 … ``` This would allow more simplified CI/CD jobs with the two most important CI systems, GitLab CI and GitHub Actions. Both allow to pass environment variables to other jobs by writing them to a specific file (as documented for [GitLab](https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job) and [GitHub](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#passing-values-between-steps-and-jobs-in-a-workflow)). The first step of the pipeline would calculate the GitVersion-variables and export them, and all subsequent jobs could use those variables. One important thing to consider is what to do with `null` values. In the example above, `BuildMetaData` is `null`. If it's in the output, the environment variable will be defined as empty. But most probably, all GitVersion-variables that are `null` should not be printed at all in `dotenv` mode.

[rose-a]

I suggest they should be prefixed with GitVersion_ (i.e. GitVersion_AssemblySemVer) to avoid name collisions.

I'd strongly recommend writing out null values because then they would explicitly override/reset previously set values. Not doing that could lead to potentially weird results for people using those variables (like PreReleaseLabel for instance).

That would basically be the exact output of the GitLab build server integration (albeit to the console)...