[BUG][Typescript-Fetch] Regression on date query parameter serialization

[mggevaer]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists? ->(Tried both 5.4.0 and 6.0.0 SNAPSHOTS)
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Date type serialization for date-time format query parameter does not seem to work.
The expected behavior would be to create an ISOstring, but instead simple string conversion is used.

HOLD ON
This could just be user error on my side, the issue should be fixed according to this PR in 5.1.0 but I was not able to get decent Date query serialization on the 5.1.0 jar
#8616

openapi-generator version

5.1, 5.4, 5.4-SNAPSHOT, 6.0.0-SNAPSHOT, It might be a regression, since this should have been fixed on 5.1

OpenAPI declaration file content or url

openapi: 3.0.3
info:
  title: badDateSerialization
  version: '1.0'
servers:
  - url: 'http://localhost:3000'
paths:
  '/some-endpoint/{datetime}':
    parameters:
      - schema:
          type: string
          format: date-time
        name: datetime
        in: path
        description: a datetime
        required: true
    get:
      summary: ''
      operationId: get-users-userId
      responses:
        '200':
          description: OK

Results in this DefaultApi:

https://gist.github.com/MartijnGevaert/5352550eae90acb53138fc519a5ffd6c

Generation Details

In my project:
java -jar ./openapi-generator-cli.jar generate -i ./backend_openapi_spec.yaml -o ../../react_frontend/src/Api/generated -g typescript-fetch

Steps to reproduce

Creating the fetch api frontend code without any options whatsoever results in the behavior.

Related issues/PRs

#8616

Suggest a fix

It seems that the related PR mentioned above has a commit AFTER the branch has been merged, this might contain the fix for this issue.