Support vendoring for insecure (HTTP) OCI registries

### Describe the Feature

Currently, atmos vendor pull for oci:// sources does not provide a built-in, declarative way to specify that an OCI registry should be accessed over plain HTTP (insecurely). This is necessary when working with OCI registries that are not configured with HTTPS, such as local development registries or airgapped in-cluster registries behind a service mesh.

### Expected Behavior

Users should be able to configure an OCI component source in the vendor.yaml to be pulled over plain HTTP (currently seems limited to HTTPS).

### Use Case

This feature is important for several scenarios:

- Air-gapped Environments: Internal OCI registries in air-gapped networks often use HTTP or self-signed certificates that are not trusted by default.
- Private In-Cluster Registries: Kubernetes clusters often deploy with internal container registries (e.g., for caching or local images) that might be exposed over HTTP within the cluster network or via a service mesh.
- Development & Testing: Developers frequently use local, ephemeral OCI registries (e.g., a local Docker registry instance) for quick testing, which may not have HTTPS configured.
- Service Mesh Scenarios: In environments with service meshes (e.g., Istio, Linkerd), TLS termination might happen at the mesh level, and services within the mesh might communicate over HTTP. Atmos needs to be able to interact with OCI registries in such setups.

Without this, users are forced to implement workarounds like custom vendoring scripts (bypassing atmos vendor pull for OCI) or complex environment variable management.

### Describe Ideal Solution

Introduce a new boolean attribute, for example oci_insecure: true (or oci_plain_http: true), to the OCI source configuration within vendor.yaml
```
spec:
sources:
- component: "terraform-null-label"
source: oci://my-insecure-registry.example.com/terraform-null-label:{{ .Version }}
version: "0.0.1"
# Proposed new flag for OCI sources
oci_insecure: true
```

When oci_insecure: true is set:

1. Atmos would recognize this flag for OCI sources.
2. Given that Atmos appears to utilize github.com/google/go-containerregistry for OCI operations (as suggested by internal/exec/oci_utils.go and PRs #1093 ), this flag would instruct Atmos to use appropriate options with the go-containerregistry library (e.g., remote.WithPlainHTTP) to allow connections over plain HTTP for this specific OCI source.

### Alternatives Considered

1. Using a custom script with `oras pull --plain-http`: This bypasses atmos vendor pull for OCI components, losing the many benefits of Atmos's integrated vendoring management. This is the current workaround I'm uses to test a broader PoC.
2. I tried setting GO_GETTER_INSECURE_REGISTRIES: env but it likely doesn't apply to OCI pull functions in atmos (couldn't get it working).
3. Vendor modules from local filesystem via [k8s OCI volume](https://kubernetes.io/docs/concepts/storage/volumes/#image) *edit: just ran across this / added here but haven't tried it yet

### Additional Context

_No response_

Start by reading internal/exec/oci_utils.go and the vendor.yaml source example, then trace the atmos vendor pull entry point for OCI sources. Confirm how go-containerregistry options are passed and verify that the proposed insecure setting enables plain-HTTP pulls for that source without changing HTTPS behavior.

Written by the indexing model from the issue text.