refactor: enforce single param on sending/editing methods

[castdrian]

Please describe the changes this PR makes and why it should be merged:
This PR refactors the methods across the the lib's sending/editing methods to avoid inconsistent overloads by removing multiple param options and enforcing single param usage as laid out in #5771.

(and let's pretend that there isn't a typo in the branch name)
Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• I pretend to know how to update typings and have done so, or typings don't need updating
• This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[ImRodry]

I don't see a reason for this to be done, but either way the docs are wrong

[monbrey]

I like this change, it had been in the back of my mind for a while. I'd argue that we should do the same thing to <TextChannel>.send though, and enforce an object everywhere.

[castdrian]

I like this change, it had been in the back of my mind for a while. I'd argue that we should do the same thing to <TextChannel>.send though, and enforce an object everywhere.

Yes same, refer to internals, I got the go from Crawl to refactor the rest, hence why I changed the title and converted to draft

[castdrian]

-refactored again, comment dismissed-

[ckohen]

I think this would call for a refactor of APIMessage.create as well, since it would always be an options object, splitting it out no longer makes sense to me.

[castdrian]

I think this would call for a refactor of APIMessage.create as well, since it would always be an options object, splitting it out no longer makes sense to me.

Actually probably not as I am currently refactoring to what the maintainers have internally decided upon, crawl laid it out in details in #5771

[ckohen]

I did read the linked issue, it suggests only content should ever be provided standalone. meaning all the checks in APIMessage.transformOptions should never be hit, the whole purpose of those checks is to allow what is being removed here.
There will need to be a check whether options is a string though.

Something for the maintainers to address, should we still be able to pass an APIMessage to these methods still? I think it can be quite useful, but not sure if its wanted.

You can also just pass options to APIMessage.create already anyways, no need to options.content, options

[castdrian]

Yeah I got a go on what to do, it's been discussed to pretty much do what the issue says and merge it into one param, and yeah I saw that the apimessage creation param is optional, will adress that :)

Stale

[SpaceEEC]

Seems like I missed two:

[austr1an]

Some examples were not changed :

discord.js/src/structures/interfaces/TextBasedChannel.js

Lines 146 to 158 in 7b2e12b

	* channel.send('This is an embed', {
	* embed: {
	* thumbnail: {
	* url: 'attachment://file.jpg'
	* }
	* },
	* files: [{
	* attachment: 'entire/path/to/file.jpg',
	* name: 'file.jpg'
	* }]
	* })
	* .then(console.log)
	* .catch(console.error);

I saw another but it got patched while I was writing this comment lol

[austr1an]

same here :

discord.js/src/structures/interfaces/InteractionResponses.js

Lines 167 to 170 in 7b2e12b

	* interaction.update("A button was clicked", { components: [] })
	* .then(console.log)
	* .catch(console.error);
	*/

[kyranet]

Are you able to open a PR fixing those docs, @AustrianDev?

If so, it'd be nice if you could work on those, otherwise let us know and a contributor will work on those 👍🏼

[austr1an]

Ok, I will