Is your feature request related to a problem? Please describe.
When outputting into the same package it's quite tedious to having to specify the full package name with goverter:output:package. This is an albeit small friction point, but still feels like goverter should be able to figure this out for us instead of us having to input this.

I want to only need to specify goverter:output:file. The issue with this comes when you want to both output into the same package and reference some other functions.

For example, given this:

package sample

import "strings"

// goverter:converter
// goverter:output:file ./generated.go
type Converter interface {
	// goverter:map Moo | Uppercase
	ConvertFoo(foo Foo) Bar
}

type Foo struct {
	Moo string
}

type Bar struct {
	Moo string
}

func Uppercase(s string) string {
	return strings.ToUpper(s)
}

When generating it outputs this:

// Code generated by github.com/jmattheis/goverter, DO NOT EDIT.
//go:build !goverter

package generated

import sample "goverter-test/pkg/sample"

type ConverterImpl struct{}

func (c *ConverterImpl) ConvertFoo(source sample.Foo) sample.Bar {
	var sampleBar sample.Bar
	sampleBar.Moo = sample.Uppercase(source.Moo)
	return sampleBar
}

This fails to compile because the default package name is generated, and having two different package names in the same dir is not allowed:

$ go test ./pkg/sample
found packages generated (generated.go) and sample (sample.go) in /home/kallefagerberg/code/gh/goverter-test/pkg/sample

If you override just the package name with // goverter:output:package :sample then it correctly says package sample in the generated file, but it still fails to compile because it is still importing the sample package from the sample package itself.

$ go test ./pkg/sample
package goverter-test/pkg/sample
	imports goverter-test/pkg/sample: import cycle not allowed

The only way to get around this today is to write the fully-qualified package name (as the docs suggest).

Describe the solution you'd like
It would be much nicer if the output package name defaulted to the package name that's already used in that directory (if any). If none exist, then you can default back to generated again.

This new behavior should apply if you leave goverter:output:package unset.

By looking around Go's parsing packages, I found this which could help: https://pkg.go.dev/golang.org/x/tools/go/packages#example-package

For example if I have the following repo:

 .
 ├── pkg
 │   └── sample
 │       └── sample.go
 ├── go.mod
 ├── go.sum
 └── main.go

And in the main.go I have the following code:

func main() {
	cfg := &packages.Config{
		Mode: packages.NeedName,
	}
	pkgs, err := packages.Load(cfg, "./pkg/sample")
	if err != nil {
		log.Fatalf("Load: %s", err)
	}
	for _, pkg := range pkgs {
		log.Printf("Package ID: %s", pkg.ID)
		log.Printf("Package name: %s", pkg.Name)
	}
}

Running it results in this:

$ go run .
2025/01/29 17:39:52 Package ID: goverter-test/pkg/sample
2025/01/29 17:39:52 Package name: sample

(I named the module goverter-test with go mod init goverter-test).

Describe alternatives you've considered
An alternative could be to instead programmatically try get the module name (the goverter-test part), and then resolve what the full package name would be. This would mean it would be able to assume the full package name with this too:

// goverter:converter
// goverter:output:package mygeneratedconverter
type Converter interface {
	ConvertFoo(foo Foo) Bar
}

although I don't think it has any benefit if goverter is aware of the full package name when it's not using other files...