The variable tracking has the issue that it needs a trigger by the Tag
Manager to pick up the variable. This causes some trouble with the
quality of our tracking right now. Therefore, we try to use more
triggers from the code. The first one should be the opening of
Lebensmonate. The former count value of the variable can be derived in
the tracking system.

While being the repository default, this wasn't possible for a while due
to some restrictions of older Vitest versions.

Since we are using the `eslint-plugin-tailwindcss` this is no more
needed. The ESLint plugin does the same and can do more. Theoretically
a separation between linting and formatting is great. But unfortunately
not always possible.

In result the Prettier configuration was left empty. So it got deleted.
In future we would like to use the new file name and TypeScript (i.e.
`prettier.config.ts`).

We try to uniformly use the emerging standard of tools in the JavaScript
space to use configuration files in plain JavaScript or even TypeScript
with naming like `<tool_name>.config.{js,ts}`. TypeScript is preferred,
but not supported by StyleLint yet.

This adds a few additional configuration options to report invalid usage
of comments to disable rules.

The directory of `user-tracking` was quite unpleasant when opened. This
is partially due to the very expressive names of the metrics. But there
was also a lot of things mixed together all in one.
The new directory names should provide a little more guidance. Though,
the term `core` is a very generic word that is abused too often. With
further added complexity to it, its likely it should get separated from
the application and put into its own package. Only the application
specific metrics should then remain there. Potentially even aligned with
their related application features.

The features should be very independent and somewhat agnostic. After
all, they should be segregated from the routing logic. This
responsibility has to be pushed upwards.

What was special about this, were the usage of routing after forms got
submit. Furthermore, the submit/navigate button is outside the layout of
the form components of the abfrageteil feature. To solve this, an
external submit button is used. This was enabled by simple optional
properties for the forms. Thereby, testing remains stable and there is
no coupling to any routing logic at all.

Within this commit, the ButtonGroup component was resolved. This led to
kinda repetitive code. Anyhow, there is no 100% clear re-usable
structure yet. The costs are minimal.

This is an old design pattern that was still kept alive. Though, since
the project has moved the maintainer, it never felt just right anymore.
Anyhow, there were 0 organisms left, 2 atoms and a bunch of molecules.
Furthermore, the pages components never really fit into this scheme.

The new structure is not perfect, but should go into the right direct
and simplify things. The whole routing/pages part is not well refined
yet. But they have a stronger bonding than being re-usable components
for all features.

There are still some wild cross project dependencies that need to be
sorted. Some could be resolved with this commit.

It is currently not 100% clear what is and what could be a shared
re-usable component. Though, these have been moved to clear the
directory structure even more.

This is a very independent part of the application which has already
been shifted in the past. Its not re-usable component and also doesn't
belong to any other feature.

There is no reason to expose this from the feature itself. It exposes
a much larger interface than actually necessary. This also means the
tests have shifted. Though, they basically stayed exactly the same.

Notice that the navigation issue isn't solved yet. The feature should
not know how to navigate where. But this is a broader issue in itself.

This is just the first step. This is a very messy process for this
feature. There are plenty of cluttered interfaces and cross
relationships. But to maintain some usable history in the version
control system, this commit tries to limits its impact.

We already used `immer` for other tests, as it leads to much cleaner,
shorter and less messy tests (in context of Redux, which uses immer
itself).

Furthermore, the test utilities now expose the created store to further
simplify the usage in tests.

Moreover, the exported interface of the individual Redux slices has been
reduced to simplify dependencies. This will help future refactoring.

It might be very a big exaggerated to define this as a feature of the
user-interface. Anyhow, it is a collection of resources that as a whole
and should be free to move around. It should not matter where this user
feedback is actually integrated in the application. This is especially
true with our recent considerations to find better placements.
There is some dependency inversion to the tracking layer in place. This
is actually great, but feels a bit awkward in the context of the state
management in parallel to it. However this will be kept for now.

The code was kept close to the original. Though, some improvements based
on a good feature interface was made.

There were also minor improvements to some tests and code around the
Redux store management.

These algorithms are solely used by the elterngeldrechner. Anyhow, they
are kind of an dependency by the calculation. Historically this actually
was an external library. Before we had to replace it with a custom
implementation. Encapsulating this package provides some structure and
more overview in the elterngeldrechner. The latter now primarily focuses
on the implementation of the law and their guidelines.

The current approach uses a very strong/direct dependency model without
any inversion or injection. This might be some work for future
refactoring, nevertheless should be mentioned here.

Currently this logic is primarily used by the applications planer
feature. Thereby, it was located in the domain of the monatsplaner. But
this is only co-located by usage. Actually this a much more fundamental
logic which gets used by other features too. But for example the
elterngeldrechner package implements its own (wrong/buggy)
lebensmonatrechner too.
This should help to sharpen the focus of the different packages and
increase their re-usability.

With the previous work to carve out some core "packages", the (majority)
leftovers where collected into the application directory. This continues
the intent to build up a stronger and more clean project directory
structure.
The term of just `application` is very generic, though widely adopted.
As we don't have multiple applications/entry-points yet, there is no
further naming necessary as typical monorepo tooling would apply.

This is a follow up on the intent to create a stronger and more clean
project directory structure. It finishes with the former suspicious
`globals/js` directory. A remnant of old migrations.

The naming of `elterngeldrechner` is a but unlucky, taking the
repository name itself into account. Though, the former `calculations`
does not properly fit too. But the repository (and the production
webiste) name isn't the best too. Therefore, this name is currently the
best for this package.

This a first step of the intention to give the project a stronger and
more clean structure. A stronger emphasize on the directory structure
and naming should help. It is a potential intermediate step into further
structuring measurements.

It also starts to extend the code documentation. A first README local to
the new montasplaner package provides initial helpful information.

There is a hypotheses we need to verify. Therefore new data must be
tracked. As always: the new tracking variable will be picked up by a new
version of the tag manager.
The naming of the tracking variable and associated function, module, ...
is not great. Though, it nails it pretty much down to what is actually
is.

Unfortunately, after some refinement for what we actually need to track,
this is quite low level, down in the monatsplaner feature. We still
wanna keep the features focused and segregate responsibilities like
tracking. As the result, there is quite some "callback drilling" through
the component tree to forward the toggle event for the `<details>`
elements. As this event usually does not bubble by default, there is no
other possibility to observe this behavior. We hope this remains an
exception and might be removed soonish.

Instead of creating a new type for the HTML element referenced, it just
forwards the `<details>` element itself and improves the `focus` method
of it. This is a more universal solution that will allow further
features using the forwarded reference for something else but the focus.

The number of callbacks exposed by the monatsplaner feature starts to
grow. The former approach to use optional, positioned arguments does not
scale well. Therefore, this was restructured.

Furthermore, the naming was strengthened. Callbacks that are associated
1:1 with a use-case of the Planer service use the same naming now.
Though, the expressiveness of the `onPlanChanged` was reduced to
`onChange`. But it uses the same verb presence as typical for events and
it re-uses a commonly used term that everyone is familiar with. The
context of the monatsPLANER should do the rest.

Moreover, some tests have been added to actual test that the callbacks
are actually called. These have been partially missing.

The original implementation is highly outdated and unmaintained. There
is a fork that seem promising and gets used by many users of the former
checker.

Same rules as for clean code to improve communication and readability.

According to the motto: the stricter the better. All fixes were simple
and straight forward.
Also removed unused flags and those which just repeat the default.

This reverts commit 2a6afb6b.

Gewinneinkünfte and Lohneinkommen require different information by the
user. The calculation interface currently provides a unified model for
both as one. This is problematic. Especially because this leaked into
the user interface. Which led to users providing wrong inputs due to
a misleading visual interface.

Design has improved this and we have now alternative inputs for
Gewinneinkünfte. Under the hood it was also important to change the data
model of the form/store. Which then gets transformed into the model of
the calculation.

The whole code around the components etc. is highly copy-pasted and
still ugly and cumbersome. Anyhow, this is a small step into a better
world.