Make sure custom configuration file path is returned when custom configuration is set

[kucuk-furkan]

Description

In this pr, /config argument usage controlled and issue when using it fixed.

• Introduce a new test method ReturnConfigurationFilePathIfCustomConfigurationIsSet in ConfigurationFileLocatorTests.cs to
  verify custom config file handling.
• Update GitVersion.Configuration.Tests.csproj to copy Configuration/CustomConfig.yaml to the output directory.
• Enhance GetConfigurationFile method in ConfigurationFileLocator.cs to return the custom config file path if set and exists.
• Add CustomConfig.yaml with various versioning settings.

Related Issue

Resolves #4480

Motivation and Context

This bugfix resolves #4480 issue. In earlier changes there is a change to how should tool locating configuration files. It cause a problem if /config arguments is used. Now if its used and configuration file is presents, locator returns custom configuration file path directly.

This isn't a problem before this change merged. In dotnet Path.Combine method handles if path is rooted automatically. But with this pr, tool stops using Path.Combine and starts directly looking under givin directory path. For further information, you can check this Microsoft documentation. In this documentation; we are interested with combine method's examples section - path1 and path3 combine example -.

How Has This Been Tested?

All existing tests pass.
New tests added.

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[HHobeck]

I have reviewed your code changes.

[arturcic]

@kucuk-furkan please check why the the tests fail on ubuntu

then I can review the code

[kucuk-furkan]

@arturcic i didn't fix it on purpose to ask this. I shouldn't be the decider i think. I'm just a user of this tool and try to help fix my issue.

Tests fails because of this Also if i apply your suggestion, tool stops working as case insensitive. Case insensitive support was added couple weeks ago. I'm not sure this suggestion should be applied or not

Either i can remove those tests too or put back case insensivity support back. What should i do? Someone who responsible for this project tell me what to do. I think leaving managing case sensivity to OS is better choice. But someone opened this as an issue then fixed it.

Which direction should i go?

[arturcic]

The case insensitive should be kept for the default file names, for the custom config file probably better to leave it to the OS

[arturcic]

@kucuk-furkan please make sure you do rebase of your branch on top of main branch, instead or mergin main into your branch. We prefer to have clean history and it's clear where the PR branch started in the history

[kucuk-furkan]

@arturcic i think its ready now. Tests looks fine. I rebased my fork and for cleaner look, i squashed my commits.