Move plugin-level metadata out of individual plugin versions

[aufi]

Background

Plugin manifests currently repeat plugin-level fields in every entry under versions:

kind: Plugin
versions:
- name: OpenShiftPlugin
  shortDescription: OpenShiftPlugin
  description: This plugin generates transformations related to OpenShift cluster specifics.
  version: v0.1.0
  binaries: ...
- name: OpenShiftPlugin
  shortDescription: OpenShiftPlugin
  description: This plugin generates transformations related to OpenShift cluster specifics.
  version: v0.1.1
  binaries: ...

The plugin name and descriptions normally apply to the plugin as a whole, not to a specific version. Keeping them in every version introduces duplication and allows values to become inconsistent.

PR #20 from @djzager proposed moving these fields to manifest-level metadata. It should be closed because it is outdated, conflicts with the current branch, points the index at a contributor fork, and is not supported by the current crane data model.

Proposed change

Define plugin-level fields once in the plugin manifest:

apiVersion: crane.konveyor.io/v1alpha1
kind: Plugin
metadata:
  name: OpenShiftPlugin
shortDescription: OpenShift transformations
description: This plugin generates transformations related to OpenShift cluster specifics.
versions:
- version: v0.1.0
  binaries: ...
  optionalFields: ...
- version: v0.1.1
  binaries: ...
  optionalFields: ...

The final schema should be agreed on before implementation. In particular, we should decide whether descriptions are typed top-level fields or annotations under metadata.

Required work

• Update the plugin manifest types and parsing in migtools/crane.
• Update listing, filtering, and installation code that currently reads name, shortDescription, and description from PluginVersion.
• Decide whether existing manifests must remain supported during a transition period.
• Add parser and plugin-manager tests for the new format.
• Migrate all manifests in crane-plugins.
• Update the manifest format documented in README.md.
• Keep index URLs pointed at the canonical repository and branch.
• Validate plugin metadata once per manifest and version-specific data once per version.

Acceptance criteria

• Plugin-level metadata is declared only once per manifest.
• crane plugin-manager list displays the plugin name and descriptions correctly.
• Listing and installing specific plugin versions continues to work.
• All repository manifests use the agreed schema.
• Documentation matches the implemented schema.
• Automated tests cover parsing, listing, and selecting a version.
• The migration and backward-compatibility policy is documented.

Related: #20