Report transform plugins origin and run mode

[aufi]

Summary

Extend crane transform list-plugins so each plugin reports:

• its runtime origin: embedded or external: <discovery-directory>
• whether it runs automatically when crane transform is invoked without an explicit stage: default or opt-in

Example:

Plugin: KubernetesPlugin (version v0.0.10, source embedded, run default)
Plugin: OpenShiftPlugin (version v0.1.0, source embedded, run default)
Plugin: BuildConfigToBuildsPlugin (version v0.1.0, source embedded, run opt-in)
Plugin: ExamplePlugin (version v1.2.3, source external: /work/plugins, run default)

Motivation

Users need to understand which plugins are compiled into the binary, which were loaded from an external directory, and why an available plugin such as BuildConfigToBuildsPlugin is not run by an implicit multi-stage transform.

Requirements

• Preserve the existing Plugin: <name> (version ... prefix so simple text parsers remain compatible.
• Preserve current plugin precedence and de-duplication: embedded plugins first, then local, explicit, global, and package plugin directories.
• --skip-plugins must continue to omit skipped plugins.
• Report the discovery directory for the winning external plugin.
• Do not report plugin-manager as a runtime source. A discovered executable cannot reliably prove whether it was installed by a plugin manager or copied by a user.

Implementation direction

Introduce a plugin descriptor in the discovery layer containing the plugin, source kind, source directory, and enabledByDefault. Keep the existing plugin-only helper as a compatibility wrapper. Have transform list-plugins format descriptors rather than bare plugin metadata.

Tests

Cover embedded default plugins, embedded opt-in BuildConfigToBuildsPlugin, external plugins from each discovery location, duplicate-name precedence, skipped plugins, and output-prefix compatibility.