feat(frontend) Support vendor branding

[grolu]

What this PR does / why we need it:

• Moved vendor assets from src/assets to public/static/assets to make them replaceable with custom assets
• GVendorIcon component serves icons from this directory using filenames from vendor information
• Centralized dictionary for vendors (infra/dns/image) in config store
• Added defaults for all known vendors (displayname, icon, weight)
• All values can be extended or overridden via configuration
• Removed need to provide createTitle and updateTile in GSecretDialog (now kebap-case generated from displayName)
• Use vendorDisplayName everywhere to ensure we show configured name for vendors instead of technical name

Which issue(s) this PR fixes:
Fixes #1707 Fixes #207 (partly)

Special notes for your reviewer:
Open Questions:

• Do we want to deprecate vendorHints config and move hints to the new vendor configs?
• Do we want to move vendor customization under ´frontendConfig.branding` config

TODO:
Adapt helm charts (values.yaml)

Release note:

Vendor Branding
- Define order, name and icon of cloud providers in dashboard configuration
- Define order, name and icon of machine image vendors in dashboard configuration

[klocke-io]

Looks a lot cleaner and simpler now 🎉

[klocke-io]

showing an example config file would be nice

[gardener-robot]

@holgerkoser You have pull request review open invite, please check

[petersutter]

do you think it makes sense to have a vendorDetailsMap computed prop? In order to compute it once? Something like the following

  const vendorDetailsMap = computed(() => {
    const map = new Map()

    // Build map from all known and configured vendors
    const allVendors = new Set([
      ...knownVendors.map(v => v.name),
      ...configVendors.value.map(v => v.name),
    ])

    for (const kind of allVendors) {
      const configuredVendor = find(configVendors.value, ['name', kind])
      const knownVendor = find(knownVendors, ['name', kind])

      map.set(kind, {
        name: kind,
        weight: Number.MAX_SAFE_INTEGER,
        ...knownVendor,
        ...configuredVendor,
      })
    }

    return map
  })

  function vendorDetails (kind) {
    return vendorDetailsMap.value.get(kind) ?? {
      name: kind,
      weight: Number.MAX_SAFE_INTEGER,
    }
  }

[grolu]

Yes. While working on your feedback i stumbled over that comment that there could be possible name clashes between the different vendor arrays. As they are already separated in config, I changed the code to include a type in the vendorDetails lookup.
As I did not want to adjust every component that uses the function to pass the param, I do this internally only and log a warning in case there are ambiguous or missing vendors. This, however slightly reduces the performance effect we gained by introducing the computed as we now have to loop over the types in the compatibility function. However this will change once we pass type from the components using the function

[gardener-robot]

@grolu You need rebase this pull request with latest master branch. Please check.

[petersutter]

vendorDetails only accepts one (name) param

[petersutter]

shouldn't we better name it to knownOSImageVendors or knownMachineImageVendors? Or do you think it is clear enough?

[gardener-ci-robot]

The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:

• After 15d of inactivity, lifecycle/stale is applied
• After 15d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 7d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Mark this PR as rotten with /lifecycle rotten
• Close this PR with /close

/lifecycle stale