Support custom markers for packages out of api/

[buraksekili]

Hi team,

First of all, thank you for your work in maintaining this tool. It has been incredibly useful for our project.

I have a use case where my CRDs share common types that are defined outside of the api/<version_number> package, as mentioned in issue #58.

While adding the +groupName and +versionName markers allows dependent packages to be included in the generated documentation, I've encountered a challenge. In my case, adding these k8s-related markers causes issues with internal tooling. Specifically, adding the +versionName marker breaks the functionality of controller-tools. As a result, this solution isn't feasible for my use case; thus, some of the fields in the generated crd docs are not pointing anywhere. Unless I miss something, there is no way for me to use another marker tag to specify the values read by +groupName and +versionName in dependent packages.

At the moment, the tool supports custom markers (this is how I overcame my issue). I was wondering if you would consider extending the functionality to allow the use of custom marker tag keys for +groupName and +versionName, as seen in the following section of the code:

crd-ref-docs/processor/processor.go

Lines 235 to 243 in 95ad38c

	groupName := markerValues.Get("groupName")
	if groupName == nil {
	return nil
	}
	version := pkg.Name
	if v := markerValues.Get("versionName"); v != nil {
	version = v.(string)
	}

.

Instead of the following, which is also recognized by controller-gen:

// +groupName=my.group.io
// +versionName=v1alpha1
package common

Perhaps we could implement custom markers like this:

// +mygrouptag=my.group.io
// +myversiontag=v1alpha1
package common

These custom tags (+mygrouptag and +myversiontag) could then be defined through the config file, as shown below:

processor:
  includePackages:
    "github.com/myorg/my-operator/api/common": # Go package name
      groupNameTag: "mygrouptag"  # Custom tag for groupName
      groupVersionTag: "myversiontag"  # Custom tag for versionName

This would provide great flexibility. I already have a toy implementation I use => buraksekili@99f5b67.

Regardless of the proposed solution, any suggestions or ideas to address this issue are most welcome.
Thank you!