Unify @PlanningId usage across quickstarts

[mcimbora]

@PlanningId usage is a bit inconsistent across the quickstarts, use it on all problem fact & entity classes.

13.1. @PlanningId
For some functionality (such as multithreaded solving and real-time planning), Timefold needs to map problem facts and planning entities to an ID. Timefold uses that ID to rebase a move from one thread's solution state to another's.
To enable such functionality, specify the @PlanningId annotation on the identification field or getter method, for example on the database ID:

Current status:

timefold-quickstarts/use-cases/employee-scheduling - @PlanningId defined both on planning entity and problem facts
timefold-quickstarts/use-cases/food-packaging - @PlanningId defined on a single planning entity, not on problem facts
timefold-quickstarts/use-cases/facility-location - @PlanningId not used at all

[ge0ffrey]

Potentially related info:

For the quickstarts that switched to UI-has-full-solution-state (school timetabling and vehicle routing* currently), we've also changed the ID type to String. All quickstarts will sooner or later be refactored accordingly.
That new approach has no database, so no need to keep that ID as a number.

Motivation: most users want to reuse their own ID for input data such as an employee (name is not unique and often obfuscated) and that ID type can be anything from a number to an UUID. String always fits.