Add options for import file extensions (.js/.ts) and type-only imports

## Problem

The generated client uses **extensionless, value-only relative imports**:

```ts
import { ApiResponse, Pet, User } from "./data-contracts";
import { ContentType, HttpClient, RequestParams } from "./http-client";
```

This form does not work in two increasingly common TypeScript setups, and there is currently no built-in option to change it.

### 1. Missing file extensions on relative imports

With `moduleResolution: "node16" | "nodenext"`, TypeScript/Node require explicit extensions on relative imports. The generated `./data-contracts` / `./http-client` specifiers fail to resolve at runtime (ESM) and are flagged by the compiler. Projects using `allowImportingTsExtensions` have the same need, but with `.ts` instead of `.js`.

There is no way to tell the generator to emit `./data-contracts.js` (or `.ts`).

### 2. Value imports break `verbatimModuleSyntax` / `isolatedModules`

Type-only names (data contracts, `RequestParams`, `HttpResponse`, and `ContentType` in `enumStyle: "union"`) are imported as **values**. Under `verbatimModuleSyntax` (and `isolatedModules` with certain bundlers) this is an error — those imports must be `import type` (or carry an inline `type` modifier).

Note the http-client import is **mixed**: `HttpClient` is a runtime class (extended/instantiated) and must stay a value import, while `RequestParams`/`HttpResponse` are type-only. So a whole-block `import type` is wrong there — it needs per-specifier inline `type`:

```ts
import { HttpClient, type RequestParams, type HttpResponse } from "./http-client";
```

The data-contracts import, by contrast, is entirely type-only and can use a whole-block `import type`.