[http-client-java] emitter support for constant optional parameter with `@clientDefaultValue`

## Context
From Search: https://github.com/Azure/azure-rest-api-specs/pull/41045/changes
Emitter now will generate many constants for them: https://github.com/Azure/azure-sdk-for-java/pull/48415/changes

We could do a `@alternateType` to eliminate these generated enums, e.g.
```typespec
@@alternateType(Search.acceptHeaderNone.accept, AcceptHeaderNoneConstant, "java");
enum AcceptHeaderNoneConstant {
APPLICATION_JSON_METADATA_NONE: "application/json;odata.metadata=none";
}
```

Search is converted from Swagger. Previously they don't have this parameter:
https://github.com/Azure/azure-rest-api-specs/blob/ea07d130a2ae2c15dac79797bea6a8cc43f20b45/specification/search/data-plane/Azure.Search/preview/2025-11-01-preview/knowledgebase.json#L36

Now they have this, but we may want to keep the client API unchanged(no breaking change, at least for now).

TypeSpec way of doing this be:
```typespec
@header
@Legacy.clientDefaultValue("application/json;odata.metadata=minimal")
accept?: "application/json;odata.metadata=minimal";
```

## Solution
Discussion so far concludes at, making this parameter required with a fixed value, if we see `@clientDefaultValue` combined with `param?: "constant`. Existing logic already makes required + constant hidden from API.
Until we support `@clientDefaultValue`.

Question: Do we want to apply only to `Accept` header, or in general?
Personally, I'd say since it's a hack for Search, we only do it for `Accept`.

Alternatives:
1. pass `clientDefaultValue` to Java generator and set `required` there. This is too leaky.
2. only pass `clientDefaultValue` for `accept` header. Still leaky, and benefit not evident.