[Feature Request]: Incorrect links to multi-version CRDs

[tswangdi]

I used crd-ref-docs to generate API documentation for a multi-version CRD.

# API Reference

## Packages
- [example.dev/v1](#exampledevv1)
- [example.dev/v2](#exampledevv2)


## example.dev/v1

### Resource Types
- [Foo](#foo)
- [FooList](#foolist)

#### Foo                        
                                <- Jump to here

## example.dev/v2

### Resource Types
- [Foo](#foo)                   <-  Click this 
- [FooList](#foolist)

#### Foo
                                <- Expect to jump to here

Clicking on the v2 version of Foo redirects to the v1 version of Foo

Refer to the implementation of Kubernetes Docs

[antonincms]

We also have this issue on Markdown output. I had the idea I had to fix it would be to add HTML anchors to markdown title by replacing #### Foo with #### <a id="example-dev-v2-foo">Foo</a> and replace links [Foo](#foo) with [Foo](#example-dev-v2-foo).

We also have this issue with Markdown output. My idea to fix it is to add HTML anchors around markdown titles like so #### <a id="example-dev-v2-foo">Foo</a>.

I tried to fix it in templating by replacing the anchor #### {{ $type.Name }} with #### <a id="{{ markdownTypeID $type }}">{{ $type.Name }}</a>. I also replaced package links {{ $gv.TypeForKind . | markdownRenderTypeLink }} with {{ $type := $gv.TypeForKind . }}{{ markdownRenderExternalLink (printf "#%s" ($type | markdownTypeID)) $type.Name }}.

However, it does not seem as straightforward, since markdownRenderTypeLink skips native types, and since for field links the behavior of markdownRenderType is more complex, so I guess we would need to modify both implementations, probably in a breaking way for markdownRenderTypeLink.

I made a fix that I could upstream if that's ok with maintainers.