Block Editor: Generate consistent suggestion object by URL

[aduth]

Related: #19816

cc @getdave

Work in Progress: Sharing this pull request early to explore ideas and possible solutions. Not all of it makes sense, and much of it could be paired down to smaller, focused pull requests.

The general goals here include:

• Fix an inconsistency introduced by Block Editor: Handle LinkControl submission via form handler #19651 where "manually-entered" URLs are crafted differently depending whether they were submitted using the form handler vs. explicitly selected from the list of presented suggestions. With these changes, a single uniform getSuggestionByURL helper is used in both places.
• Try to be more explicit with the shape of these suggestion options, so that the properties of a suggestion are consistent, regardless of whether it represents a post search result or a manually-entered URL. Another effect of the changes from Block Editor: Handle LinkControl submission via form handler #19651 is that when submitting a manually-entered URL value, because it only assigns the url property, it would inherit all other properties from the previously-selected value (title, etc), which would probably not be expected.
• Realign all of the current "types" of manually-entered URLs as subtypes of the 'url' type. This is toward a goal of treating these as distinct from post-based suggestions on the basis of type, where all post or page suggestions are grouped under the 'post' type distinction. This is also consistent with existing logic for considering these values as "URL"s.
  • I have doubts about whether we really care to assign these subtypes, vs. leaving it to the consumer to deal with a URL as they see fit (especially considering we have plenty of other offerings to help classify and manipulate URLs). If we choose to assign subtypes, it's unclear to me what the best codomain set we would expect to be possibly generated, but we should want to be as explicit as possible. I think including a subtype could at least be beneficial in being consistent with the interface of a "suggestion" (as in where the subtype of a 'post' suggestion is the post type).
• Simplify the behavior of search to avoid changing the behavior of the suggestion presentation based on assumptions of the input matching some pattern of a URL. Separately (and in some informal discussion with @getdave), we might want to explore removing suggestions altogether for manually-entered URLs, since I'm not sure it makes sense for a user. If a URL is entered, it should be almost guaranteed that there won't be any useful suggestions associated with that URL. Conversely, if a non-URL is entered, the suggestions are the only thing the user cares about (there should be no offering of the "insert as URL" suggestion).

[aduth]

Some of the general refactoring might be useful to pick up again later, but for now, I will close this in favor of:

• PR Block Editor: LinkControl: Avoid lingering value properties from previous value #20020 - Block Editor: LinkControl: Avoid lingering value properties from previous value
• Issue Remove unnecessary suggestion types in LinkControl  #20051 - Remove unnecessary suggestion types in LinkControl