New resources: pipefy_table and pipefy_table_field

[Danielmoraisg]

Summary

Tables (databases) are half of most Pipefy setups and the provider cannot manage them. pipefy_automation already accepts a table as action_repo_id (the read query uses the action_repo_v2 union in internal/provider/resources/resource_automation.go), so today a config can reference a table in an automation but not create it.

pipefy_table

• Mutations: createTable (organization_id, name, plus description and authorization on the input), updateTable, deleteTable.
• Read: table(id:) query exists, so import is a plain id passthrough.
• Schema: id (computed), organization_id (required, RequiresReplace), name (required), description (optional), authorization (optional).

pipefy_table_field

• Mutations: createTableField (table_id, label, type, options, required, description), updateTableField (the API requires table_id alongside the field id), deleteTableField.
• Schema mirrors pipefy_field: id/internal_id/uuid computed, table_id required RequiresReplace, type RequiresReplace, label, required, options, description.

Notes

• Check whether table field mutations have the same concurrency restriction as phase fields; if so, reuse internal/provider/locks keyed by table id.
• Whatever lands for pipefy_field depth (description, help, editable) should land here too, so coordinating the two schemas is worth it.
• Examples, import scripts, registration in provider.go, make generate.