Add ansible plugin scaffolding command into ansible-operator binary

[chiragkyal]

Description of the change:

This PR introduces ansible plugin scaffolding by integrating the functionality directly into the ansible-operator binary under a new scaffold subcommand.

Motivation for the change:

• This change streamlines the process by providing a single, dedicated command-line tool.

Implementation Details

New scaffold Subcommand: The ansible-operator binary now includes a scaffold command, which provides all the project scaffolding capabilities (e.g., init, create api).

Unified CLI:: Users now only need ansible-operator.

• To run the operator: ansible-operator run ...
• To scaffold a new project: ansible-operator scaffold init ...
• To add a new API: ansible-operator scaffold create api ...

E2E: Uses a common CLI entrypoint for hack/generate/samples/ansible/generate.go which is used to generate e2e testdata.

Example usage

make build

mkdir memcached-operator
cd memcached-operator

../ansible-operator scaffold init --domain example.com

../ansible-operator scaffold create api --group cache --version v1alpha1 --kind Memcached --generate-role

[acornett21]

IMO this doesn't need to be a separate binary build, this will confuse uses at release time. Just make this plunging available at the top level of the existing cmd entry point.

[camilamacedo86]

We might not want to have base.ansible.sdk.operatorframework.io/v1 since it is not a base for Ansible ( only Ansible code without the config/ generated by kustomize/v2 ), so we might wish to to change it to be called ansible.operatorframework.io/v1

[chiragkyal]

Thanks for the suggestion. Updated the plugin name to reflect ansible.operatorframework.io/v1

[camilamacedo86]

We should not include this code here.
Instead, we must ensure that the hack generator uses the actual binary, rather than mocking the CLI and invoking it directly.
The binary should be built locally and used during generation to validate that everything functions correctly—this is the approach taken in the Operator SDK.

Reference: operator-sdk/hack/generate/samples/generate_testdata.go#L30-L37
c/c @acornett21 ^

[chiragkyal]

The binary should be built locally and used during generation to validate that everything functions correctly—this is the approach taken in the Operator SDK.

I think the current approach follows a deliberate design choice made in #4 PR, after which we are now generating the testdata on the fly using the helper library.
This PR is trying to unify the testdata generation with the binary's command execution. We created a single entrypoint (GetPluginsCLI()) that is called by both the main function for the final binary and by the hack script that generates the test samples.
It ensures that our testdata is always generated using the exact same logic and configuration that the end-user's binary will have. It creates a tight coupling that prevents any possible divergence between the test suite and the released artifact.

This change is a continuation of the existing pattern. I think we are not breaking the testdata generation flow or logic.