Mark and visualize aliases for the api-docs

[ST-DDT]

Clear and concise description of the problem

Methods should refer to related methods to improve visibility for developers, so they can find replacement/alternative methods more easily.

E.g. The developers searches for an android app package name. The developer finds the hacker module with the appleBundleId, then sees that it is an alias and now finds the internet.domainName method that they use until they PR their new method here.

There might also be value in the reverse alias.
E.g. the developer wants and appleBundleId, but searches for reverse domain names and thus stumples across the internet.domainName method and there they discover that the method they need exist already.

Suggested solution

Use jsdocs @alias to refer to the core of an implementation.

E.g.

[...]
 * @alias faker.internet.domainName
 */
appleBundleId() {

However there are some things that needs to be defined, before we can add this.

1. Where do we add these:

• All methods that depend on another faker method (e.g. faker.datatype.number() and faker.datatype.boolean())
• All methods that depend mostly depend on a single other faker method (faker.random.arrayElement())
• Only methods that are an alias for a non helper/random/datatype method (e.g. faker.internet.domainName(params)

2. Which information should we include in the link

• Only the method name faker.internet.domainName
• Method with parameters faker.internet.domainName(reverse: true)

3. Should we include links back to the aliases
   e.g. faker.internet.domainName <-> faker.hacker.appleBundleId

• Yes (automatically)
• Sometimes (manually)
• No

4. How should they be displayed?

• Similar to @see? (Above or below or mixed with @see?)
• ???

Alternative

• Use @see to link these methods together
• Use js/ts AST to generate the alias references automatically
• Don't link the methods together

Additional context

The issue originally came up during #1154 .

[ST-DDT]

This is mostly covered by @see tags already.