This commit implements Redis caching for the `TimeEntry` object to address the following requirements:

- Persistence of Time Entry state across restarts: TimeEntry objects are now cached in Redis, allowing the application to recover the state after a restart or crash.

- Scalability and consistency across multiple servers: By storing TimeEntry data in Redis, all instances of the application can access the same data, ensuring consistency when scaled across multiple servers.

- Improved performance for time-sensitive operations: Caching TimeEntry objects in Redis reduces the overhead of fetching data from the database, leading to better performance for time-sensitive operations like time tracking.

The following changes were made:

- Added `TimeEntryCacheManager` class to handle Redis caching operations for TimeEntry objects.
- Implemented caching of TimeEntry objects in relevant methods of `TimeEntryServiceImpl` and `TimeEntryTrackingServiceImpl` using `@Cacheable` and `@CachePut` annotations.
- Implemented cache eviction for the `TimeEntryService#deleteTimeEntry(TimeEntryId)` method using the `@CacheEvict` annotation.

With these changes, the application now meets the specified requirements for state management, scalability, and performance using Redis as a caching solution.

 #13)

# Issue
We encountered a `LazyInitializationException` when trying to access the `timeSegmentList` of a `TimeEntry` object that was retrieved from the cache. This happened because the `timeSegmentList` was lazily loaded by Hibernate, and we were trying to access it after the Hibernate Session had been closed.

# Temporary Solution
We resolved this issue by forcing the initialization of the `timeSegmentList` before caching the `TimeEntry` object. We did this by calling `size()` on the `timeSegmentList` in the `getTimeEntryById` method. This ensured that the list was fetched from the database and included in the cached `TimeEntry`.

```java
timeEntry.getTimeSegmentList().size(); // This will initialize the timeSegmentList
```
> ## Note
>  This solution might have performance implications if the timeSegmentList is large, as it will always be fetched from the database even if it’s not needed. Therefore, this solution is not recommended for large data sets. We are currently exploring more efficient solutions.