Fix: WriteConfig file extensions check

[greg-szabo]

Fixes #427 .
Closes #428 .

This PR sets the assumption that if the developer ran SetConfigType during the loading of a config, they should be able to save the config without concern to the file extension.

The current behavior is that the file extension takes precedence during saving, even when SetConfigType was explicitly run.

For example, if the developer loads a .config file by setting the config type to TOML, calling WriteConfig will fail with Unsupported Config Type ".config", even though the developer explicitly told the framework before that it's a TOML file.

The main impact on current use-cases show well in testing: filenames with the wrong extensions are now written in the format defined in SetConfigType, instead of based on the file extension.

[CLAassistant]

All committers have signed the CLA.

[sagikazarmark]

@greg-szabo Thanks a lot for the contribution and the well-formulated PR.

As much as I like it though, it's unfortunately a breaking change. The current behavior expects that the file extension takes precedence over the manually configured type (we had a similar situation here: #813 (comment)). Whether that's a good behavior or not is kind of irrelevant from the backward compatibility promise point of view.

As I understand, in the following scenarios this patch would break that promise (correct me if I'm wrong):

• file: config.json, type: yaml
• file: .json, type: yaml

I can think of a number of workarounds though to make sure these cases would still work the way they should, and turn to the configured type if all else failed (ie. check if the file extension is supported and use it if it is).

Some tests covering these cases would also be nice.

Let me know if you think I misunderstood something and thanks again for the contribution!