[TypeScript-fetch] expose the path of each method (e.g. testing purposes)

[jonas-pietzsch]

Our team uses the typescript-fetch generator and has a lot of unit tests which mock HTTP responses that the generated client executes. In order for tests to know the HTTP paths to mock it would be helpful to let the generated API project also expose the paths of the API methods.

The most simple idea we came up with is to simply offer public members in the TypeScript API classes per API method. This makes it easy to use in case you need it but still optional and non-intrusive.

I didn't create an issue for this change because it's no misbehaviour and at this point I could find any downsides of the change. Let me know if this is something that is really necessary.

I re-generated all sample clients for TypeScript-fetch (checked in), started the petstore API locally and ran the integration tests locally.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. (@amakhrov ping)

[wing328]

@jverhoelen if you still want to get this PR merged, please resolve the merge conflicts.

Next time, please also cc TS technical committee to review the change:

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02) @davidgamero (2022/03) @mkusaka (2022/04)