autoobs & link: handle corner cases better with respect to observation previews

[synrg]

A grab-bag of corner cases to consider handling better with respect to handling observation previews:

1. If ,link https://www.inaturalist.org/observations/12345 is given, and previews are allowed on the channel, Discord provides a preview of the image, and ,link also does

• this is almost never what the user wanted, but they can fix it by either pressing X on the spurious preview by Discord, or go back and edit their message to put angle brackets around the URL

2. If autoobs is on for a channel or server, and a URL is pasted to a channel where preview permission is removed for the user who pasted it, the image preview is suppressed, but the autoobs kicks in and shows the summary without the image.

• depending on the server admin team's wishes, this may or may not be the intended result, i.e. they may wish to support autoobs actually including the image here

3. If autoobs is on for a channel or server, and previews are allowed, Discord's automatic preview image is above the summary within the user's message instead of below (as in ,link output)

• this is really bad looking. until Discord gives us this requested feature, there's not much we can do here without the bot having permissions it currently doesn't have: https://support.discord.com/hc/en-us/community/posts/360042180911-Link-Preview-Remove-or-hide-preview-on-a-per-image-basis
• if we had that feature, then previews of observation links could be suppressed, and the bot could be wholly responsible for displaying its output below the previewed image
• there are other ways it could be handled, though, which we considered in early design of autoobs and rejected as "too complex" and also "too intrusive", generally requiring the bot to have Edit Messages permission, such as deleting the auto preview from the user's message, or editing the user's message to completely reformat it as what they typed, followed by the embed content

These go in different directions to smooth over the limitations of what the Discord api allows us to do today, and besides, may address issues that nobody actually cares about the way we have our servers & channels configured today. If we decide to do anything about any one of them, the idea we choose should probably be the new Subject of this issue & the others split off or discarded.