Fix gofmt group separator placement in Go import add/remove

[knutwannheden]

Motivation

Removing the first import of a grouped block leaves a stray blank line immediately after the opening paren. A gofmt import group separator is spelled as a blank line on the prefix of the import that opens the group, so when the import ahead of a group boundary is deleted, that blank line is orphaned onto the front of the block. RemoveUnusedImports is invoked automatically by templateRecipeVisitor whenever an after-template declares SourceImports, so the artifact lands in a large share of the diffs these recipes produce.

// in
import (
	"io/ioutil"

	"example.com/plainpkg"
)

// out, before this change
import (

	"example.com/plainpkg"
)

Pulling on that thread showed the same root cause on the insertion side: insertGrouped copies a neighbouring import's prefix onto the new import, which drags that neighbour's group separator along with the indent. The separator then lands wherever the donor happened to sit rather than on the group boundary, and all four insertion positions get it wrong — joining an existing group gains a spurious blank line, opening a new group at the head or the tail gets none. This was originally reported as "adding an import appends it as its own third group", which is the tail case. It is a whitespace bug, not a grouping-policy choice: placement is unchanged, an import still goes at the end of its own group.

Note for anyone bisecting: a reproduction that uses a versioned import path (gopkg.in/yaml.v3 and friends) will appear to start failing only once the companion PackageName fix lands. On today's main such an import is deleted outright as unreferenced, the block collapses, and there is no separator left to orphan. The defect is pre-existing and independent of that fix; the tests here use plain paths so the two are decoupled.

Summary

• RemoveFromBlock collapses the group separator on the element it promotes to the head of the block. Removal elsewhere in the block is untouched.
• insertGrouped composes the new import's prefix from the block's indent plus a separator when the preceding import belongs to another group, instead of copying a neighbour's prefix wholesale. Inserting ahead of every existing import moves the separator onto the import displaced from the head.
• SortByGroup shares the separator helper, so the spelling of a separator lives in one place.
• Landed as two commits so the insertion change is separately attributable. It turns out to cause no downstream churn: the moderneinc/recipes-go expectation that pins this behaviour ("encoding/json/v2", "os", "encoding/json/jsontext") is a single stdlib group with no separator in play, and produces byte-identical output before and after — verified against this branch.

Test plan

• TestRemoveUnusedImports_DropsFirstOfGroupedBlock — removing the first element of a grouped block leaves no leading blank line (fails before, passes after).
• TestRemoveUnusedImports_KeepsGroupSeparatorWhenDroppingMiddle — pins that a mid-block removal keeps the separator on the following group.
• TestAddImport_OpensNewLeadingGroup / TestAddImport_OpensNewTrailingGroup — a new group at either end gets a separator.
• TestAddImport_JoinsExistingLeadingGroup / TestAddImport_JoinsExistingTrailingGroup — joining an existing group gets none.
• go build ./... && go vet ./... && go test ./... green from rewrite-go/ (16 packages, no failures).