Add support for passing base path for control plane operations

[rohanshah18]

Problem

Currently users don't have an option to pass in the base path for control plane operations.

Solution

Add host and enableTls fields to Pinecone's inner class called Builder and further set the same values for PineconeConfig. This allows the same configuration to be used for data plane operations, eliminating the need for users to manually instantiate PineconeConfig and pass it to the Pinecone class, as was required in the previous approach..

Existing approach for data plane operations:

// Instantiate ManageIndexesApi class
ManageIndexesApi manageIndexesApi = new ManageIndexesApi();

// Instantiate PineconeConfig class
PineconeConfig config = new PineconeConfig("apiKey");
// Disable tls for gRPC calls
config.setTLSEnabled(false);
// Set host for gRPC calls
config.setHost(host);

// Instantiate Pinecone class using PineconeConfig and ManageIndexesApi
Pinecone pinecone = new Pinecone(config, manageIndexesApi);

// Get index connection object for the index
Index index = pinecone.getIndexConnection("index");

// Upsert records into the index
index.upsert("v1", Arrays.asList(1f, 2f, 3f));

New approach for control and data plane operations:

// Sets the host for both control and data plane operations
Pinecone pinecone = new Pinecone.Builder("apiKey")
       .withHost(host)
       .withTlsEnabled(false)
       .build();

// Create index (control plane operation)
pinecone.createServerlessIndex("index", "cosine", 3, "aws","us-east-1", DeletionProtection.DISABLED);

// Get index connection object for the index
Index index = pinecone.getIndexConnection("index");

// Upsert records into the index (data plane operation)
index.upsert("v1", Arrays.asList(1f, 2f, 3f));

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Infrastructure change (CI configs, etc)
• Non-code change (docs, etc)
• None of the above: (explain here)

Test Plan

Existing integration tests should work as it and tested locally using the emulator.

[austin-denoble]

This looks ok to me, but I had a couple questions since it's been a while since I've looked at this codebase.