feat(Message): replace reply functionality with inline replies

[almostSouji]

Please describe the changes this PR makes and why it should be merged:

⛔ Fully moved into #4874

original:

This PR removes Message#reply from the library as it is just a convenience shortcut for

<Message>.channel.send(`${<Message>.author}`, content)

Before it was argued that the added benefit of adding the reply recipient as parsed mention to the respective options was indeed a considerable ease of use compared to the #send call with all required options to make this work, however Discord has recently had previews for inline replies in development client and rumors of a new message type (19) being the proper implementation after the initial tests have reached us.

While this is not yet officially confirmed in any discord API documentation cleaning the namespace to provide actual reply functionality (should it be available for bots in the first place) or keeping it clear due to the associated meaning of the term "reply" brought forward by aforementioned functionality.

The implementation of the feature itself can then take place in a minor release, while the clearing of the name space (this PR) obviously requires a semver: major, thus me making this PR now, aiming it for v13 together with using the new API versions.

• remove the method from the code base
• remove from APIMessage options
• remove from typings
• remove from boilerplate
• remove from examples
• remove from test files

Should I have missed any caveat please do let me know!

Status

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating

Semantic versioning classification:

• This PR changes the library's interface (methods or parameters added)
  • This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
• This PR only includes non-code changes, like changes to documentation, README, etc.

[almostSouji]

Designing around making this compatible with current API functionality in place is a bigger issue than anticipated. #4874 will become major (v13) and include breaking changes instead, fully incorporating this PR.