fix: fall back to default value if foreign key of `join_numpy` is unresolved

[lars-reimann]

What problem do you want to solve?

Closes #740

join_numpy now takes a value that is used if a foreign key cannot be resolved, e.g. because it is explicitly set to -1.

Todo

• [X] Pick an appropriate title.
• [X] Put Closes #XXXX in the first PR comment to auto-close the relevant issue once the PR is accepted. This is not applicable if there is no corresponding issue.
• [ ] Document PR in CHANGES.md.

[lars-reimann]

1. Currently, a default value must always be specified. Would that suffice for now?
2. Should there still be a check of the validity of foreign keys? I've kept it for non-negative foreign keys.
3. A default value for _unterhaltsvorschuss_empf_eink_above_income_threshold must still be added.

[hmgaudecker]

1. I think the name "default" is misleading a bit. Maybe: "value_if_foreign_key_is_missing"? Too long, maybe... But yes, we should be explicit there.
2. Validity checks for non-negative numbers sound good.
3. That'll be up to @MImmesberger

Thanks!!!

[MImmesberger]

I just renamed the new argument and adjusted the join for Unterhaltsvorschuss accordingly.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.41%. Comparing base (23e7b4f) to head (42c5eca).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #741 +/- ## ======================================= Coverage 89.41% 89.41% ======================================= Files 51 51 Lines 3646 3647 +1 ======================================= + Hits 3260 3261 +1 Misses 386 386 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.