microcks import truncates Windows absolute paths when parsing :primary suffix

Dieses Issue hat noch niemand übernommen.

### Describe the bug

`microcks import` supports an optional `:true` / `:false` suffix to mark whether an imported artifact is the main artifact. However, the current parser at `cmd/import.go:126` uses `strings.Split(f, ":")`, which also splits Windows-absolute paths on the drive-letter colon. A path such as:

```text
C:\Temp\api.yaml
```

is therefore truncated to just `C`, and the remainder is treated as the boolean suffix — which then fails to parse, falls back to `mainArtifact = true`, and the upload step opens `C` (which does not exist).

---

### Expected behavior

Windows-absolute paths should be preserved as full file paths.

`C:\Temp\api.yaml` should be parsed as:

```text
path = C:\Temp\api.yaml
mainArtifact = true
```

`C:\Temp\api.yaml:false` should be parsed as:

```text
path = C:\Temp\api.yaml
mainArtifact = false
```

The existing documented suffix behavior should continue to work for relative paths:

```text
./api.yaml -> path = ./api.yaml, mainArtifact = true
./api.yaml:true -> path = ./api.yaml, mainArtifact = true
./api.yaml:false -> path = ./api.yaml, mainArtifact = false
```

In short: the parser should be able to tell the *drive-letter* colon apart from the *suffix-separator* colon.

---

### Actual behavior

The current parser splits on every colon and only ever inspects `parts[1]`.

A Windows path like `C:\Temp\api.yaml` is parsed as:

```text
parts = ["C", "\Temp\api.yaml"]
path = "C"
mainArtifact = true (strconv.ParseBool fails on "\Temp\api.yaml", default is true)
```

A Windows path with an explicit suffix like `C:\Temp\api.yaml:false` is parsed as:

```text
parts = ["C", "\Temp\api.yaml", "false"]
path = "C"
mainArtifact = true (only parts[1] is read; the trailing "false" is never seen)
```

In both cases the subsequent upload fails with `open C: no such file or directory`, with no hint that the parser silently truncated the path.

---

### How to Reproduce?

1. On Windows, place an OpenAPI file at `C:\Temp\api.yaml`.
2. Build the CLI: `make build-local`.
3. Run:
```bash
./build/dist/microcks.exe import C:\Temp\api.yaml --microcksURL http://localhost:8585
```
4. Observe the failure: `open C: no such file or directory` (sometimes preceded by `Cannot parse '\Temp\api.yaml' as Bool, default to true`).

The same shape of bug is reproducible on Linux/macOS by passing a path that contains a colon, e.g. `path:with:colon.yaml`.

---

### Microcks version or git rev

_No response_

---

### Install method (`docker-compose`, `helm chart`, `operator`, `docker-desktop extension`,...)

_No response_

---

### Additional information

**Root cause.** `cmd/import.go:125-131` parses each comma-separated entry by:

```go
if strings.Contains(f, ":") {
pathAndMainArtifact := strings.Split(f, ":")
f = pathAndMainArtifact[0]
mainArtifact, err = strconv.ParseBool(pathAndMainArtifact[1])
...
}
```

Beginne in cmd/import.go:125-131, wo durch Kommas getrennte Import-Einträge mit strings.Split geparst werden. Baue mit make build-local und teste relative Pfade, Pfade im Windows-Laufwerksstil sowie Pfade mit expliziten true- oder false-Suffixen. Als erledigt gilt, dass der vollständige Pfad erhalten bleibt und das Suffix weiterhin mainArtifact bestimmt, ohne das bestehende Verhalten für relative Pfade zu beeinträchtigen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.