test(handlers): add table-driven interface tests

[nathaniel-itential]

Description

Adds handler_table_test.go with a baseline global handler test, checking command count, RunE existence, and basic arg validation.

Ended up finding multiple issues with the existing description files, summarized below:

• describe
  • methods, views, role-types, adapter-models, configuration-parsers have no describe entry in their descriptor file
  • gctrees has an entry but is disabled
• Create
  • Prebuilts
• clear
  • Profiles, adapters
  • gctrees is disabled
• Copy
  • Roles has only copy as a method, no copy from or copy to resulting in it not actually picking up the copy interface
• Edit
  • Workflow is missing describe entry

Type of Change

• Bug fix
• New feature
• Documentation
• Refactor
• Chore

Changes Made

Adds a handler_table_test.go file that contains 3 main components: A interface table that stores the expected method for each handler interface (eg. Reader has Get and Describe commands), a handler table that has each handler with the types they are expected to be (Eg accounts is just a Reader), and a generic handler test that ensures there is the expected commands for a handler given the types, they have runE, and if they require args they have at least one declared.

Testing

Ran make build and ran the handler tests.

Checklist

• Code follows the project's style guidelines
• Self-review of code has been performed
• Code has been commented where necessary
• Tested with make setup or relevant profile
• Commits follow conventional format (type: subject)
• No secrets or credentials committed
• Documentation has been updated accordingly
• PR has been labeled appropriately (enhancement, bug, documentation, refactor, chore)

[nathaniel-itential]

Currently tests are failing due to the issues mentioned in the PR summary, I will most likely get around to fixing some of those issues next week. I will keep this PR open for now and update when I fix the issues.

[nathaniel-itential]

@wcollins The tests for this are failing due to the fact that some tests are picking up that there are undefined methods (such as in methods.go runner, where there is no implementation for the describe method). This is due to in some cases an oversight in the api routes, where there is no existing api route. That being said, how should we handle this? Should we make the tests more granular, down to declared methods (get, describe, create) instead of interface (reader, writer, etc)