Java-Core to Gax Mapping Tracking Ticket

# Problem

The Java SDK has a split in some runtime functionality between Java-Core and Gax for some client libraries. Historically Java-Core was maintained by older handwritten teams and contains mostly the same functionality that exists inside Gax. Gax is modern and actively maintained by the Cloud Java team and to ensure that features have complete coverage in the Java SDK, the features must be added to both Java-Core and Gax. We cannot get rid of Java-Core without potential breaking changes and migrating all use cases to Gax may not also be possible.

# Solution(s)?

1. Java-Core's functionality serves as a wrapper around Gax that is used for older, existing handwritten libraries. Java-Core should delegate the actual logic to Gax so that there is a single source of truth. Changes required from new features should only be made to Gax and can be applied to all the client libraries in the SDK.

## Areas to consider creating a mapping
1. Settings/ Options (ServiceOptions -> ClientSettings)
2. URL Resolution (Resolve Host -> EndpointContext)
3. Executor logic (Deprecation of DirectExector and replace with ScheduledExectuor)?

Begin by comparing the listed Java-Core and Gax areas: ServiceOptions with ClientSettings, Resolve Host with EndpointContext, and DirectExector with ScheduledExectuor. The issue does not name files or tests; completion would require defining and implementing a complete mapping without breaking existing handwritten client libraries.

Written by the indexing model from the issue text.