Implementation EPS

[bakhterets]

What this PR does

Implements full support for the Enterprise Project Service (EPS) v1 API, adding the following capabilities:

• Project management (openstack/eps/v1/projects): List, Get, Create, Update, and Action (enable/disable) enterprise projects
• Resource management (openstack/eps/v1/resources): Filter resources by enterprise project and migrate resources between projects
• Provider listing (openstack/eps/v1/providers): Query services that support enterprise projects
• Version listing (openstack/eps/v1/versions): Retrieve available EPS API versions
• Client initialization: NewEPSV1 added to openstack/client.go using initClientOpts with "eps" type
• Acceptance client: NewEPSV1Client in acceptance/clients/clients.go with domain-scoped authentication and endpoint derivation from IAM URL

EPS is a global (non-project-scoped) service that is not present in the Keystone service catalog, requiring domain-scoped token authentication and manual endpoint construction.

Which issue this PR fixes

#935

Special notes for your reviewer

• EPS requires domain-scoped authentication (no project scope), which is different from most other services. The acceptance client derives the EPS endpoint from the IAM URL (iam.{region}.xxx → eps.{region}.xxx).
• Unit tests cover all CRUD operations with mock HTTP fixtures.
• Acceptance tests cover the full project lifecycle (create → update → disable → enable), version listing, provider listing, and resource filtering.
• The NewEPSV1 client function follows the standard initClientOpts pattern used across the codebase.

[anton-sidelnikov]

Hi @bakhterets, please look at the FSG or API Gateway services, which follow the current SDK architecture. The implementation here appears to use the older OpenStack approach, which is less reliable in our environment

We should also remove the explicit .Extract() calls. The extraction logic must be handled within the request itself