[core] Move overwrite ownership to SupportingFile

[jimschubert]

Previously, there was a writeOptional method in DefaultCodegen which
allowed *Codegen instances to immediately write out a supporting file if
it did not exist. This would allow a codegen implementation to skip
user-facing options such as definitions in .openapi-codegen-ignore, the
"supportingFiles" system property, and support for the experimental
handlebars templating engine. While our implementation only modified the
supportingFiles list conditionally, it added confusion as it seemed to
imply that file writes were somewhat the responsibility of
DefaultCodgen (it's DefaultGenerator which handles file manipulation).

This commit moves the definition of whether a file supports overwriting
existing files into the SupportingFile type itself, allowing that
functionality to be determined at time-of-write rather than
time-of-definition. This would allow us, for example, to dump the list
of files which would be generated using a --dry-run option or similar.

This will be a breaking change for anyone who has extended
DefaultCodegen and called "writeOptional". The path to migrate is to add
the SupportingFile to the supportingFiles list and chain the method call
.doNotOverwrite() on the instance.

This has the added benefit of clarifying this behavior, considering the
write behavior wasn't previously "optional" writes but optionally
defining the list of supportingFiles based on the state of the file
system.

Fixes #4582

This is both a bug fix (due to previous behavior of potentially circumventing user options) and a breaking change (due to workflow options exposed to users via DefaultCodegen rather than DefaultGenerator).

cc @OpenAPITools/generator-core-team

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[jimschubert]

I should clarify:

Our writeOptional implementation would previously only add the file to the supportingFiles list if the file didn't exist. Being a method in DefaultCodegen, there's nothing that would have prevented someone from writing immediately (like if someone said "Why isn't writeOptional actually writing?").

There's technically nothing stopping users from circumventing DefaultGenerator's workflow and writing files whenever they want from a Codegen implementation, but this aims to clarify ownership of that behavior as before the SupportingFile would sometimes be in the list of supporting flies and sometimes would not be in the list.

[jimschubert]

I've squashed and force-pushed, trying to add clarification to the commit comment and PR description about my concerns with the previous behavior.