uint64/int64 fields in Istio CRDs cannot be set via apimachinery

**Bug description**
If a CRD defined via protobuf contains a primitive int64/uint64 field, it will be impossible to set using kubernetes client-go. The API server will log a validation error along these lines:

```
spec.subsets[0].trafficPolicy.loadBalancer.consistentHash.maglev.tableSize: Invalid value: "string": spec.subsets[0].trafficPolicy.loadBalancer.consistentHash.maglev.tableSize in body must be of type integer: "string""
```

**Affected product area (please put an X in all that apply)**

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience

**Expected behavior**
The expected behavior is that the resource will be created without API errors.
I would suggest either of the following solutions:
- Add the cue-gen:DestinationRule:intOrString:xxx option
- Change the uint64 to uint32 in the destination_rule.proto file, specifically in the ConsistentHashLB message:
```proto
message ConsistentHashLB {

message RingHash {
// The minimum number of virtual nodes to use for the hash
// ring. Defaults to 1024. Larger ring sizes result in more granular
// load distributions. If the number of hosts in the load balancing
// pool is larger than the ring size, each host will be assigned a
// single virtual node.
uint32 minimum_ring_size = 1;
};

message MagLev {
// The table size for Maglev hashing. This helps in controlling the
// disruption when the backend hosts change.
// Increasing the table size reduces the amount of disruption.
// The table size must be prime number less than 5000011.
// If it is not specified, the default is 65537.
uint32 table_size = 1;
};

...
}
```

**Steps to reproduce the bug**
1. Define a CRD using protobuf that includes primitive int64 or uint64 fields.(e.g. tableSize field of DestinationRule)
2. Attempt to create an instance of this CRD using kubernetes client-go.
3. Observe the validation error in the API server logs.

**Version (include the output of `istioctl version --remote` and `kubectl version`)**
- istioctl version --remote: 1.16.1
- kubectl version: v1.25.2

**How was Istio installed?**
istioctl

**Environment where bug was observed (cloud vendor, OS, etc)**

MacOS sequoia v15.1.1

Additionally, please consider attaching a [cluster state archive](http://istio.io/help/bugs/#generating-a-cluster-state-archive) by attaching
the dump file to this issue.
- https://github.com/istio/api/issues/2818