[test] clientcore, test for RestProxy with types

[weidongxu-microsoft]

The handling of types in request and response is kind of ad-hoc.

For request parameter, there is a list of types

azure-sdk-for-java/sdk/clientcore/core/src/main/java/io/clientcore/core/implementation/http/rest/SwaggerMethodParser.java

Lines 617 to 637 in 263eb51

	if (value instanceof String) {
	return (String) value;
	} else if (value.getClass().isPrimitive()
	|| value.getClass().isEnum()
	|| value instanceof Number
	|| value instanceof Boolean
	|| value instanceof Character
	|| value instanceof DateTimeRfc1123) {
	return String.valueOf(value);
	} else if (value instanceof OffsetDateTime) {
	return ((OffsetDateTime) value).format(DateTimeFormatter.ISO_INSTANT);
	} else {
	try (AccessibleByteArrayOutputStream outputStream = new AccessibleByteArrayOutputStream()) {
	serializer.serializeToStream(outputStream, value, SerializationFormat.JSON);
	return outputStream.toString(StandardCharsets.UTF_8);
	} catch (IOException e) {
	throw new RuntimeException(e);
	}
	}

But for type that not in the list, the else block generally does not work correctly. See #44287

For response, it generally won't work if the type does not have a JsonSerializable. But for Java class like OffsetDateTime or Duration or byte[], they don't have it. -- This also happens when they are in a List e.g. List<Duration>.
The only one that works without JsonSerializable is Base64Uri as there is a special handling of returnValueWireType

azure-sdk-for-java/sdk/clientcore/core/src/main/java/io/clientcore/core/implementation/http/rest/RestProxyImpl.java

Lines 428 to 430 in 263eb51

	if (returnValueWireType == Base64Uri.class) {
	responseBodyBytes = new Base64Uri(responseBodyBytes).decodedBytes();
	}

---

Also, text/plain does not work (it works for Azure core). Do we need a TextSerializer?

---

canProcessEnum can pass, if we add JsonSerializable to enum.

Description

Please add an informative description that covers that changes made by the pull request and link all relevant issues.

If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[azure-sdk]

API change check

API changes are not detected in this pull request.