[Feature Request] Toggle-able mode for the Play command to search on YouTube and SoundCloud instead of picking the best result through YT alone

### Is your feature request related to a problem? Please describe.

AFAIK, #305 issue and #885 issue renders the bot seem unusable when YouTube can't return anything because the bot is designed to rely on YouTube with the default `play` command especially since people are mostly accustomed to this practice when using a Discord music bot. It is also less efficient when trying to look through both sources, and users are more likely to grab the wrong video or song especially when song covers are involved.

### What is your ideal solution to the problem?

The solution would be to give bot owners the ability to "merge `search` and `scsearch` functionality into the `play` command," through the bot config. When this is enabled, the `play` command would give options between both sources (and other potential future sources) in which users can pick between.

### Pros and Cons
**Pros**
- This allows bot owners to force users to use multiple sources rather than YouTube by default.
- Forces users to accurately pick the right song with multiple options before joining the channel and adding the song itself.
- Doesn't tuck away the SoundCloud source by default in a command nobody is usually aware of (unless intentional for some reason, would love a comment on this).
- Users can use `search` and `scsearch` to filter results to either of the sources.
- Since this is disabled by default when this is implemented, bots will be off by default.

**Cons**
- The quality of the `play` command is affected since populating the list of results depends on the search term and the quality of the search algorithms of the sources, especially since it is required that more items should be involved.
- Depending on the approach, people are more likely to prefer a YouTube result, making it less likely to help solve the #305 issue.
- It is slightly more difficult to pick the best result, especially since two sources are involved and there are no proper comparisons for sorting the songs properly by relevance.
- Some confusion for both `play` and `search` commands.

### My own suggestions based on the above
**It may be preferable to keep a single list of items, rather than categorizing them by source.**
To keep users from focusing on the YouTube list (when separated by source), the sources should be on a single list. The sources can be identifiable (as of now) with the following emojis: `▶️` and `🎵☁️` (or `☁️` alone for the sake of simplicity).

**It may also be preferable to sort the list with its own "relevance" algorithms when a single item list is involved**
The said algorithm should decide which is the best result for the user based on the information given by the sources. While I do assume that there is a certain line to be able to compare items from both sources fairly, the algorithm does not need to be overly complex if this feature is intended to be disabled by default. That being said, YouTube should be at the top of the list often due to YouTube's more accurate results.

**When YouTube doesn't return back information due to 429/captcha, only return SoundCloud and a notice**
The bot should still return results regardless, but may only have fewer items in the list and give a notice such as:
`Search results may be affected due to an error. If it persists, contact the bot owner.`

**The `search` command may be too confusing as the command itself does not refer to YouTube**
Just as how SoundCloud search is named `scsearch`, YouTube search should be named `ytsearch` while `search` should be an alias. How this works can be entirely a debate on its own.

### How would this feature be used?

1. For changes to take effect, the bot owner should enable "merge `search` and `scsearch` functionality into the play command."
2. When a user joins a voice channel and uses the `play` command, the `play` command should return search results rather than play a song instantly. It should give search results from both sources.

### Additional Info

### Intending to change the bot identity?
Since the bot was designed to primarily play music from the YouTube source, `play` and `search` function the way they are as they are supposed to. This change may be massive as I do understand that YouTube is mostly the main identity of this bot. For this case, I strongly suggested that it should be a "mode" rather than the default of the bot. The bot owners themselves are free to do whatever they need to do for their own environment. To some extent, it may change what seems to be the scope of this project, which may be well enough to decline this feature request on its own.

### What's the purpose?
The purpose is to show that the bot is capable of searching for items other than just YouTube alone. Note that in some cases, YouTube is less likely to be considered a music streaming platform in comparison to Spotify and Apple Music. SoundCloud is particularly useful in some cases and can be an okay workaround. It may also pave the way for the potential support of other sources. In my opinion, just presenting to everyone (rather than relying on bot owners to inform) that "yes, this bot does more than just YouTube alone" may well be enough to make this feature request worth it rather than holding onto a thin line of thread that is called YouTube. While I am capable of working on this on my own, I'd love to see what you guys think of it to take the time to implement this.

#### Sorry for the long post, but thank you for reading this far

### Checklist

- [X] I have checked [the documentation](https://jmusicbot.com/) to make sure this feature doesn't already exist
- [X] I have searched for [similar feature requests](https://github.com/jagrosh/MusicBot/labels/enhancement)
- [X] I have confirmed that my requests is **not** on the [list of things that will not be added](https://jmusicbot.com/things-that-wont-be-added)
- [X] I am running the latest version of the bot: 

Review the existing play, search, and scsearch command entry points and the bot configuration to understand the current YouTube and SoundCloud flows. The feature is done when an owner-configurable mode returns selectable results from both sources, handles the described YouTube failure fallback, and leaves the default behavior unchanged.

Written by the indexing model from the issue text.