Is your feature request related to a problem? Please describe.
We have recently added a mechanism to allow IBM Cloud Secrets Manager (SM) users to fetch the secret by name instead of ID as described under #2210.
This mechanism is a 2 step process with caching enabled which involves below:
Step 1: Provider calls the list API to filter the given name to find out the corresponding ID
Step 2: Provider calls the get API with the ID to fetch the secret details
This has also been documented under https://external-secrets.io/v0.9.4/provider/ibm-secrets-manager/#getting-the-kubernetes-secret.

A new API has been introduced in IBM Cloud Secrets Manager's Go SDK v2.0.1 which allows the users to fetch the secret by name through a single API call. See the corresponding API documentation for reference. This API is much more efficient than the current 2 step mechanism.

Describe the solution you'd like
We want IBM Cloud Secrets Manager provider to implement this new API in place of the existing process.
The IBM provider currently supports below formats of specifying the value of remoteRef.key in the External Secret definition:

1. <secret-type>/<secret-id> : to fetch the SM secret by secret ID
2. <secret-type>/<secret-name> : to fetch the SM secret by secret name (this is the recently added functionality)

The new API requires an additional parameter SecretGroupName referring to the name of the secret group the given secret belongs to.
In order to support the new API, the provider.go needs this input passed in as a part of remoteRef.key.
However, we don't want any breaking changes in case any user is already leveraging the existing way of getting the secret by name. We also want to replace the existing 2-step approach to the new API where the group-name is to be provided.

To tackle this, we are proposing below process to achieve this migration:

1. Add support:

• Add support to specify remoteRef.key in the format <secret-type>/<secret-name>/<secret-group-name>, where the secret-group-name is an optional parameter which is to be specified to fetch the secret by name using the new API.

2. Announce deprecation:

• There will be a deprecation notice of around 2 months (exact date is yet to be decided), where any users using the format of <secret-type>/<secret-name> should migrate to use <secret-type>/<secret-name>/<group-name> format. During this deprecation period, both <secret-type>/<secret-name> and <secret-type>/<secret-name>/<secret-group-name> formats will be supported.
• There will be a recommendation to use the new way of providing the remoteRef.key (i.e. <secret-type>/<secret-name>/<secret-group-name>).

4. Post-deprecation notice period:

• Support to use secret-type>/<secret-name> to fetch secret by name will be removed.
• In order to fetch the secret by name, specifying the secret-group-name is mandatory, i.e. remoteRef.key should be provided in the format <secret-type>/<secret-name>/<secret-group-name>.

Additional context
Note that providing remoteRef.key provided in the format <secret-type>/<secret-id> to fetch the secret by ID is unaffected and should function as usual.