feat: add intermediate result YAML saving

[sebastianJaeger]

I added a functionality that regularly saves intermediate fit results, so not all of the progress is lost upon abortion of the fit or a death of the process.

Closes #158

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (epic/99-export-fit@f4267a4). Click here to learn what that means.
The diff coverage is n/a.

@@                  Coverage Diff                  @@
##             epic/99-export-fit     #154   +/-   ##
=====================================================
  Coverage                      ?   71.54%           
=====================================================
  Files                         ?       12           
  Lines                         ?      608           
  Branches                      ?       87           
=====================================================
  Hits                          ?      435           
  Misses                        ?      142           
  Partials                      ?       31           

Flag	Coverage Δ
unittests	71.54% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

[spflueger]

@sebastianJaeger Thanks for the feature! I added a few comments.

One general thing is, that it is rather hard to test this functionality nicely. But that's more of a design issue, and I would propose to implement this functionality in a decorator (the decorator can be tested with a mock quite nicely).

If you do now have fun doing this, I can understand. But this would be a perfect time to test our new branching model in action. The idea is to push this code into a new "feature" branch. In this branch the "code quality" are not as strict as in the master branch, but allow quick additions of new features. Then those branches can be refactored and merge with the master later on. @redeboer can tell a bit more about the details

[spflueger]

I would probably just dump the dictionary as it is, without wrapping it in the "Parameters" (That's a bit of a preference though). I probably would put parameters in the automated temporary filename. Maybe @redeboer has an opinion about this.

[redeboer]

I still wrapped the parameters in a subsection, because there's also a "Time" section and "EstimatorValue".

[redeboer]

Here are a few thoughts:

• We should try to follow the interfaces of keras optimizers
• If we write to a format that can be understood by tensorboard, we may be able to use tensorboard to monitor fit progress.
• For that we need to write to different sequential log files, see also feat: add intermediate result YAML saving #154 (comment)

This would be a perfect time to test our new branching model in action. The idea is to push this code into a new "feature" branch. In this branch the "code quality" are not as strict as in the master branch, but allow quick additions of new features. Then those branches can be refactored and merge with the master later on. @redeboer can tell a bit more about the details

Since this concerns quite a few issues, I created a branch 99-export-fit that is to address #99. This has become the target branch of this PR.

[redeboer]

I updated this PR a bit with the new callback syntax (#164). Now it should also close #158, as illustrated in the notebook.

@sebastianJaeger, have a look here for the new implementation
2d621a5?file-filters%5B%5D=.py#diff-9f533f5231a0e5fcd84806765d6bbf0282451172465fee983ac5df640128cceeR34-R77

[spflueger]

All in all looks good. Just some small remarks that are not urgent (since its only going into the epic branch).

[spflueger]

I added some more ideas. But depending on how fast this functionality is needed it can be merged to the epic branch and improved there later on. Hence i approved the PR