microcks import truncates Windows absolute paths when parsing :primary suffix

Nobody has claimed this yet.

### 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])
...
}
```

Start in cmd/import.go:125-131, where comma-separated import entries are parsed with strings.Split. Build with make build-local and exercise relative paths, Windows-style drive-letter paths, and paths with explicit true or false suffixes. Done means the full path is preserved and the suffix still determines mainArtifact without breaking existing relative-path behavior.

Written by the indexing model from the issue text.