Add identifierItems support

[Kyle-Ye]

Bug/issue #, if applicable:

Close apple/swift-docc#480

Summary

Add identifierItems support to make see also link with different title

Dependencies

apple/swift-docc#505

TODO

Due to my unfamiliarity with VueJS, I can't complete the PR on the swift-docc-render side independently.

The current behavior is not as expected.

It would be highly appreciated if you can give me some help. cc @dobromir-hristov

Input

## Overview

For more information see the [specification](https://example.com).

## See Also
- [Name 1](https://example.com)

- [Name 2](https://example.com)

- [Name 3](https://example3.com)

- [this great link ![random image](https://picsum.photos/200)](https://example3.com)

with apple/swift-docc#505

Ouput

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

• Added tests
• Ran npm test, and it succeeded
• Updated documentation if necessary

[mportiz08]

I think the reason that this might not be working like you expect is that the logic for overridingTitle and overridingTitleInlineContent lives in ContentNode, which is not used by the TopicsLinkBlock component to render the see-also links (it directly uses <a> and <router-link> components).

[dobromir-hristov]

I think Marcus is right. It would probably use the overrideTitle as TopicsLinkBlock already uses the title property, but it does not know what titleInlineContent is.

Since that property is a RenderJSON format, we would have to conditionally render the ContentNode inside the TopicsLinkBlock, only when titleInlineContent is present for example. Similar to how we call renderChildren(titleInlineContent) in ContentNode.vue.

I am not sure how we should deal with the titleTag in that situation either.

[dobromir-hristov]

Should we worry about backwards compatibility? @mportiz08

[dobromir-hristov]

Because JS objects are retrieved as references, this will change the source object inside the this.references entirely, overriding the original title and content everywhere, which I think is not good.

We should create a clone of that reference, so we can safely augment things as needed.

[dobromir-hristov]

I think Marcus is right. It would probably use the overrideTitle as TopicsLinkBlock already uses the title property, but it does not know what titleInlineContent is.

Since that property is a RenderJSON format, we would have to conditionally render the ContentNode inside the TopicsLinkBlock, only when titleInlineContent is present for example. Similar to how we call renderChildren(titleInlineContent) in ContentNode.vue.

I am not sure how we should deal with the titleTag in that situation either.