feat: support mapping a content collection directory name to a site page path

In a situation where a custom collection in a directory of src/content/docs is mapped to something other than the physical content collection directory name, the wrong url is generated.

It is mentioned in the assumptions located at the top of the README that this scenario is not covered, however I think it would be fairly simple to, at a minimum, handle collection name mappings (path -> directory). Beyond that, for things like handling other path segments, it gets way more complex without internal Astro info and/or metadata in options.

For example, in the following directory structure, the [...slug].astro is written to use the content collection docs in the directory docs, however the path to the page (virtualized essentially) is my-docs/test and not docs/test.

.
├── src/
│   ├── content/
│   │   ├── docs/
│   │   |   └── test.md
|    ├── pages/
│   │   ├── my-docs/
│   │   |   └── [...slug].astro

Repro: https://stackblitz.com/edit/github-pdzrjo-gg4trc

Steps to reproduce:

Open repro
Click on any of the links in the Collection Root or Collection Subdir sections

Expected Result: The links generated should be my-docs/[slug] and navigate successfully

Actual Result: The links generated are docs/[slug] and 404

Go to the Debug page
Click any of the links and they will all work because they target my-docs/[slug]

We do not have internal information so there is no current way to detect this situation. Ideas on ways to solve for this situation:

Add an option collectionNames which is a key/value pair that makes a physical directory to the collection name. For example, using the above:

export default defineConfig({
markdown: {
rehypePlugins: [
  [
    rehypeAstroRelativeMarkdownLinks,
    {
      collectionNames: {
        docs: 'my-docs`
      }
    },
  ],
],
},
});

Leverage metadata in the link in the markdown (similar to the way classes, titles, etc. work)
```
[Some Text](some-url title){ .class-1 }
```

I think Option 1 makes the most sense as Option 2 is highly dependent on markdown processer, is very error prone and would require every link to have the metadata rather than just a single place to do the mapping as would be the case in option 1.

Thoughts? Other ideas on how to solution and if you think this scenario is worth solving for?

vernak2539 / astro-rehype-relative-markdown-links

feat: support mapping a content collection directory name to a site page path #24