Fix v2.0.0 main.go importing v1 library path (option 1 from #90)

[veggiemonk]

Implements option 1 from #90: fix main.go and retag.

Problem

On the v2 branch, go.mod declares the module as github.com/campoy/embedmd/v2, but main.go imports the v1 library path:

import (
    ...
    "github.com/campoy/embedmd/embedmd"   // ← v1 path
    ...
)

So the v2.0.0 binary actually executes v1 library code, and any consumer adding embedmd v2 as a Go tool pulls in both module versions transitively. Full repro and analysis in #90.

Changes

1. main.go — change the import to github.com/campoy/embedmd/v2/embedmd. The three embedmd.Process(...) call sites now pass context.Background() to match the v2 Process signature (the context parameter added in commit f18280f, which is what bumped the module to v2 in the first place).

2. embedmd/embedmd_test.go — same context fix. The in-package test never had its Process call updated when the signature changed, so go test ./... couldn't even compile on this branch. Splitting it into a separate commit keeps the cmd vs library fixes independent.

Verification

go build ./...     # passes
go vet ./...       # passes
go test ./...      # see note below

Known pre-existing issue (not addressed here)

TestProcess/embedding_code_from_a_bad_URL still fails after this PR:

expected: "... parse https://fakeurl.com main.go: invalid character ..."
got:      "... parse \"https://fakeurl.com main.go\": invalid character ..."

This is a net/url error-format change in newer Go versions (URLs are now quoted in parse errors). Independent of #90 and predates this PR — happy to send a separate fix if you'd like.

Suggested follow-up

After merge, tag v2.0.1. Existing v2.0.0 consumers update once and the dual-version dependency disappears.