feat: bring embed builder field manipulation in line with underlying array functionality

[almostSouji]

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

• remove MessageEmbed#spliceField
• add MessageEmbed#spliceFields
• allow multiple fields to be replaced/inserted
• update typings accordingly
• add MessageEmbed#addFields
• remove MessageEmbed#addField
• support multi-field input as Array and rest parameters
• bump node to 11 for Array#flat

The applied approach brings the embed utility methods more in line with the underlying actions done on the raw field array (push, splice) while (hopefully) cleanly handling both rest parameters as well as array passing.

While it does remove some convenience, namely .addField("foo", "bar") we discussed that keeping both #addField and #addFields simultaneously should not be the way to go, adding more noise to the interface than necessary (see the earlier deprecation of #addFile in favor of #addFiles)

• If there are really strong opinions of library maintainers i can of course revert the #addField removal
• the change to splice however adds utility in freely modifying embed fields while not removing any functionality that is currently in and should definitely be considered

Example

const e = new Discord.MessageEmbed()
			.addFields(
				{ name: 1, value: 1 },
				{ name: 2, value: 2 },
				{ name: 3, value: 3 },
				{ name: 4, value: 4 }
			)
			.spliceFields(2, 1,
				{ name: 'foo', value: 'bar', inline: true },
				{ name: 'foo2', value: 'bar2', inline: true });
message.channel.send(e);

ℹ Both methods also support the fields to be provided as an Array
⚠Due to the use of Array#flat this will require a min node bump to 11

TODO:

• refactor checkField to accept multiples and be named normalizeFields
• add MessageEmbed#addFields
• remove MessageEmbed#addFields
• bump min node
• test typings

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.

[PyroTechniac]

This looks great! Can you also bump the node version in the package.json engines field?

[PyroTechniac]

Also, looking into it, can't a generator function be introduced to flatten arrays without having to bump to a different node version?

[iCrawl]

Also, looking into it, can't a generator function be introduced to flatten arrays without having to bump to a different node version?

This won't be necessary as we are probably going to target 12 anyway, latest LTS

[almostSouji]

As Pyro pointed out on the server:
This needs to also handle addBlankField to some capacity.

• remove it, since it's really just adding a field with a zero width space
• keep it as is and use .addFields in the background
• keep it and adapt it to addBlankFields taking a number

I'm personally in favor of 1, as from experience tempering with embed layout using blank fields never yields the desired result in the first place, even more so after the rather recent embed update in which discord restyled embeds.

Edit:
As of feedback from crawl and space: removed it in the following commit