Expose `versions` as a map keyed by `v<number>` instead of a list

[grubmeshi]

Summary

Change the read-only versions output from a list to a map keyed by v1, v2,
v3, … (one key per version number; the value object stays unchanged: uuid, number,
state, content_hash).

This affects:

• meshstack_building_block_definition resource — versions is a schema.ListNestedAttribute
  today (building_block_definition_resource_schema.go:599), backed by
  Versions []buildingBlockDefinitionVersionRef (building_block_definition_resource_model.go:30).
• meshstack_building_block_definitions data source — same shape, mirrored as a
  schema.ListNestedAttribute (building_block_definitions_data_source.go:148) backed by
  []buildingBlockDefinitionDataSourceVersionRefModel. Changed for consistency so the two outputs
  don't diverge.

version_latest and version_latest_release are unchanged — they are separate computed
single-nested outputs, not derived from user-side indexing of versions.

This is a breaking change.

Motivation

versions is indexed positionally today (versions[0], versions[1], …). The 1:1
correspondence "index 0 → v1, index 1 → v2, …" is fragile: versions may be deleted in the
future, at which point a positional index no longer maps to a stable version number and any
config relying on versions[N] silently points at the wrong version.

A map keyed by v<number> makes the output stable and self-describing: versions["v3"]
always refers to version number 3 regardless of how many versions exist or were removed, and a
missing version is simply an absent key rather than a shifted index.

Breaking-change impact

• User configs that index the list positionally must migrate:
  versions[0] → versions["v1"], versions[2].uuid → versions["v3"].uuid, etc.
• meshstack_building_block_v2 wires spec.building_block_definition_version_ref from
  version_latest / version_latest_release (see the example configs and
  building_block_v2_resource.go:152), not by indexing versions, so the common v2 path is
  unaffected. Only configs that reach into versions directly need updating.

Implementation notes

• Schema: schema.ListNestedAttribute → schema.MapNestedAttribute in both the resource schema
  and the data source schema (MapNestedAttribute is already used elsewhere, e.g.
  building_block_v2_resource.go:45). Keep versionAttributes as the nested object.
• Models: []buildingBlockDefinitionVersionRef → map[string]buildingBlockDefinitionVersionRef
  (and the data source's []…DataSourceVersionRefModel → map[string]…).
• Population in SetFromVersionClientDtos (building_block_definition_resource_model.go:286-294):
  build the map with key fmt.Sprintf("v%d", *versionDto.Spec.VersionNumber) instead of writing
  to a slice index. The current ascending-sort + last-element logic that derives
  version_latest / version_latest_release must no longer rely on slice positions — derive the
  latest from the highest version number directly (or retain a sorted slice locally for that
  derivation, but expose the map). Apply the same to the data source's convertBBDVersionRefs
  path and the 403 status.Versions fallback (building_block_definitions_data_source.go:241,276).
• Docs/examples: re-run task generate; update any example .tf that indexes versions.
• CHANGELOG.md: add a breaking change entry.
• The version client is v1-preview; per the cross-repo -preview compatibility handshake,
  coordinate the minimum-compatible provider version if this output shape is consumed by the
  backend's version requirements.

Related

• Add a companion meshstack_building_block_definition_version resource #198 — companion meshstack_building_block_definition_version resource (same versions output shape; both should land the map change consistently).