Re-design `allergies`

The current exercise design has many problems:

- Students must implement a helper class `Allergen` that has no TDD style guidance
- `Allergen` is used in tests, in a `@dataProvider`. That gives hard to understand PHP errors in tests only
- `Allergen` would not be implemented that way anymore - it is a typical `enum` class

Problem specifications do not ask for a certain implementation. They define the problem statement as open as possible. Our design also should allow as many solutions as possible.

Suggestion 1: Strings and integers only

This leaves all possibilities open. Mentors can suggest `enum` or such to students. But `enum` is optimal for interfaces, internal `enum` usage just complicates things.

Suggestion 2: Provide `enum` stub

In addition to the tests from problem specifications we test the `enum` implementation first. When that is implemented, the actual problem is tested for. In these tests we must use the `enum` type, too (like `Allergen` now).

This forces students to use `enum`. It raises the bar for students not familiar with that. But `enum` would be a good choice in a real life scenario.

Suggestion 3: Provide ready-made `enum`

As before, this forces students to use an `enum` type. But the level of required knowledge is lower (only usage is required). But still, it makes no sense to work with other types internally then.

Which way to go? Other suggestions?