PB-50163 - Go-Cli : schema-driven resource type support

[cedricherzog-passbolt]

Summary

Replace hardcoded per-type structs and switch statements with a generic,
schema-driven approach using map[string]any for metadata and secret data.
This enables support for any resource type automatically (including
v5-custom-fields from Passbolt 5.3) without touching SDK code.

• Add IsSecretString(), IsV5(), HasSecretField(), HasMetadataField()
  schema introspection methods on ResourceType
• Rewrite Resource wrapper to use metadataFields/secretFields maps
  instead of discrete fields, with generic accessors (MetadataFields(),
  SecretFields(), MetadataField(), SecretField())
• Add CreateResourceGeneric(ctx, c, slug, folderParentID, metadataFields, secretFields)
  and UpdateResourceGeneric(ctx, c, resourceID, metadataUpdates, secretUpdates)
• Refactor GetResourceFromDataWithOptions to eliminate the 8-branch
  switch, now uses Metadata != "" for v4/v5 detection and
  IsSecretString() for secret format detection
• Replace slug-based check in validateSecretData with IsSecretString()
• Add v5-custom-fields fallback schema
• Remove type-specific structs (SecretDataTypeV5Default,
  ResourceMetadataTypeV5Default, etc.), keep only Secret,
  SecretDataTOTP, and encryption/decryption functions

Existing public functions (CreateResource, UpdateResource, GetResource,
GetResourceFromData) are preserved as wrappers that delegate to the
new generic implementations.

[speatzle]

I had a look, I don't think the Resource wrapper should be separate fields for username, description, password and so on.
I think a better approach would be: Have 2 maps, one for metadata and one for the Secret just like it is Server Side.

We already have a Problem with the description which sometimes becomes the Note with v5.
And with new Resource types which may not have any of these, a map would work much better.

We can have generic access functions which could work with any resource type and we can check if the requested Field exists in the Jsonschema from the Server allowing for custom resource types. Adding functions which get the often used fields and return an error if they don't exist can still be done this way.

This also eliminates all of ensureBasicFieldsParsed Since we don't need to have specific logic for resource Types.

Any thought?

[CLAassistant]

All committers have signed the CLA.