Feature/698 update a workflow by yaml

[ArBridgeman]

relates to #698

Checklist

Note: If any of the items in the checklist are not relevant to your PR, just check the box.

For any Pull Request

Is the following correct:

• the title of the Pull Request?
• the title of the corresponding issue?
• there are no other open Pull Requests for the same update/change?
• that the issue which this Pull Request fixes ("Fixes...") is mentioned?

When Changes Were Made

Did you:

• update the changelog?
• update the cookiecutter-template?
• update the implementation?
• check coverage and add tests: unit tests and, if relevant, integration tests?
• update the User Guide & other documentation?
• resolve any failing CI criteria (incl. Sonar quality gate)?

When Preparing a Release

Have you:

• thought about version number (major, minor, patch)?
• checked Exasol packages for updates and resolved open vulnerabilities, if easily possible?

[ArBridgeman]

• Check initial design with @tkilias , likely in a call
• Add structlog - bound logging so clear what's happening where as many sub-processes & multiple files
• Fix identical class names WorkflowPatcher -> original actually has a many:1 relationship and new one has a 1:1. Other naming ideas there? Or other way to think of the class?
• Create follow up PR to iterate over the workflows
• Add more test cases to the new WorkflowPatcher and to the TemplateRenderer -> multi additions, etc.
• Fix lint-importer
• Simplify workflow callers -> we have the class Workflows -> maybe that should just be a function to iterate over all of the inputs from tbx with yield to output a specific one or something?
• Likely break into 1-3 smaller PRs for reviewers

[ArBridgeman]

Semi-common use cases not covered:

• Skipping syncing certain workflows
  -> we could add to the WorkflowPatcher config a field with a list of workflow names to skip
  -> at some point for that field & workflow name, i would want to add a literal check for comparing to the active ones
• adding / modifying jobs
  -> this one is tricky as we want the users to mostly put new jobs into their own workflows. however, would we want them to be able to add to the merge-gate like so:
  https://github.com/exasol/python-toolbox/blob/main/.github/workflows/merge-gate.yml#L35
  ?
  -> when removing jobs, we don't remove them from needs yet
• modifying a matrix for a job, like
  https://github.com/exasol/python-toolbox/blob/main/.github/workflows/slow-checks.yml#L24
  -> we could change the pattern here some like creating a workflow to get out specific PROJECT_CONFIG values & returning them in a matrix. For the standard-slow tests, we could change it to get a configurable target -- just need to figure out a way to do the names...maybe there's a trip with github's json, idk
  -> maybe other / simpler ideas for that too
  -> could alternately handle if they could modify a job