[Enhancement] Should java.util.Date string conversion honor GlobalConfiguration.locale like java.time?

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/fesod/issues) and found nothing similar.

### Motivation

I noticed that `GlobalConfiguration.locale` (and the public `.locale(Locale)` builder) is documented as being used when formatting dates and numbers.

For `java.time` this matches the implementation: `LocalDateStringConverter` and `LocalDateTimeStringConverter` pass `globalConfiguration.getLocale()` into `DateUtils`.

For `java.util.Date` it does not: `DateStringConverter` never reads that locale, and `DateUtils.parseDate` / `DateUtils.format(Date, ...)` have no `Locale` parameter. The cached `SimpleDateFormat` is created with `new SimpleDateFormat(pattern)`, so it always follows the JVM default locale.

| Type | String conversion | Locale actually used |
| --- | --- | --- |
| `LocalDate` / `LocalDateTime` | `DateTimeFormatter` | `GlobalConfiguration.locale` |
| `java.util.Date` | `SimpleDateFormat` | JVM default |

I am **not sure whether this is an oversight or an intentional split**. Possible reasons I may have missed, for example:

- keeping `Date` conversion aligned with historical EasyExcel behavior and avoiding locale-sensitive parse/format changes;
- treating `Date` as an instant (timezone-oriented) and only applying locale to `java.time` types;
- considering ISO-like default patterns (`yyyy-MM-dd HH:mm:ss`) locale-insensitive, so wiring locale into `Date` was never necessary.

If this is **by design**, please say so and I will close this issue.

If it is **not** intentional, the gap may surprise users in different regions:

- The same POJO can have both `Date` and `LocalDateTime` fields. With `.locale(Locale.GERMANY)` (or `JAPAN`, `FRANCE`, etc.), only the `java.time` fields follow that locale for patterns such as `dd-MMM-yyyy` or `a` (AM/PM).
- Servers (especially Docker) often run with `en_US` / `C` as the JVM default, while the spreadsheet is meant for another audience. `.locale(...)` currently only helps `java.time` string conversion.
- Round-trip can fail: text written from `LocalDateTime` under locale `en_US` (`01-Oct-2026`) may not parse into a `Date` field if the JVM default is `zh_CN` or `de_DE`.

Numeric Excel serial dates are locale-independent; this question is only about **string** conversion of `java.util.Date`.

Could you confirm whether skipping locale for `java.util.Date` is intentional? If yes, I will close this issue. If not, I am happy to prepare a PR along the lines above.

### Solution

_No response_

### Alternatives

_No response_

### Anything else?

_No response_

### Are you willing to submit a PR?

- [x] I'm willing to submit a PR!

Start with DateStringConverter and DateUtils, then compare them with LocalDateStringConverter and LocalDateTimeStringConverter, which already pass GlobalConfiguration.locale. Determine whether java.util.Date string conversion should honor that locale; done means the project confirms the intended behavior, with matching conversion tests if a change is accepted.

Written by the indexing model from the issue text.