feat: make systemViews mergable or seperate defaults from wildcard context

[xTrekStorex]

currently when defining context "*" in the SYSTEM_VIEWS env var it will override all predefined views as in removing them.

with continued development and new predefined views this could possibly cause loss of information/features when the user defines "global" views using context "*" and does not track the changed defaults in https://github.com/gimlet-io/capacitor/blob/main/cli/pkg/server/server.go#L124 to backport them into their own config.

to prevent this configured system views should either be merged against the predefined defaults (only overriding matching IDs - preferred) or the defaults should use a reserved context seperated from "*", which would still allow defining a global context without overriding defaults.

having only "named" contexts for global views is impractical with inconsistent naming schemes across clusters (e.g. no k3d prefix). the current workaround is to either include all predefined defaults in my env var or duplicating all system views for each cluster in their own context.

[laszlocph]

The idea was that if you manage the views, you manage it all the way. Someone asked for it specifically, but I also like the feature when I install Capacitor for my consulting clients.

I could introduce a global flag like SYSTEM_VIEWS_MERGE_POLICY: merge - if set, the system views are always merged with the custom views.

Or the SYSTEM_VIEWS json could have a flag per context rule.
But It's getting a bit complicated . What do you think @xTrekStorex ?

{
  "*": {
    "includeDefaultViews": true,
    "views": [
      {
        "id": "APIPods",
        "label": "API Pods",
        "filters": [
          {
            "name": "ResourceType",
            "value": "core/Pod"
          },
          {
            "name": "Namespace",
            "value": "production"
          }
        ]
      }
    ]
  },
  "dev": {
    "includeDefaultViews": false,
    "views": [
      {
        "id": "Kustomizations",
        "label": "Kustomizations",
        "filters": [
          {
            "name": "ResourceType",
            "value": "kustomize.toolkit.fluxcd.io/Kustomization"
          },
          {
            "name": "Namespace",
            "value": "all-namespaces"
          }
        ]
      }
    ]
  }
}

[xTrekStorex]

For me personally either option would be great.

Setting a merge policy would solve the issue, but is only "safe" (no unintented removal) if set to 'merge' by default.

Adding an optional flag per context provides sane defaults and versatile configuration options while being intuitive, if it can be omitted and defaults to false (at least for all other contexts than '*'), otherwise it would add bloat.