Make SlashCommandBuilder & ContextMenuBuilder return camelCase instead of snake_case

[schblondie]

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

Changes:
This pull request makes changes in the SlashCommandBuilder and ContextMenuBuilder to make sure they return properties in camelCase as the rest of the discord.js library does. To ensure no conflicts with the API, functions were already implemented to transform the properties before creating the commands with the API. See ApplicationCommandManager & ApplicationCommand
Reason:
This makes is possible to compare the data from the Builders with the data from the ApplicationCommandManager.fetch() method, which returns a ApplicationCommand or a collection of those with camelCase properties

See also:
For further information see #9083

Follow up from #9084
I made sure to only edit properties which are not accessed by the API, as I didn't use search&replace this time

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
discord-js	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Jan 23, 2023 at 1:52PM (UTC)

[vercel]

@schblondie is attempting to deploy a commit to the discordjs Team on Vercel.

A member of the Team first needs to authorize it.

[almeidx]

You can use builders as a standalone package, that's why its separate from discord.js
The Discord API does not accept camel-cased keys, so it wouldn't make sense for @discordjs/builders to return that

[Jiralite]

Following on from the above comment:

This makes is possible to compare the data from the Builders with the data from the ApplicationCommandManager.fetch() method, which returns a ApplicationCommand or a collection of those with camelCase properties

I just commented what it sounds like you wanted, and this confirms it: this functionality already exists over at ApplicationCommand#equals().

[kyranet]

This is a semver-major breaking change, one that conflicts with what's discussed in #8015, regarding this point of data exposure:

How should the classes store the data that will be returned from toJSON() calls? In a data field or as the class fields themselves?

[...] we should instead use the data field, however no getters should be added pointing to said field

Because we will move all those properties to an internal data field, we won't have casing issues. Furthermore, builders are intended to be write-only, not read-write. In Java for example (possibly the language that uses the builder pattern the most), you cannot read the data builders write, only once you do .build(), and similar will happen here with .toJSON(). They are, after all, a middleman whose purpose is to build data in a structured way.

And because builders are intended to be used for Discord, and not for Discord.js, they must return the data that Discord expects and can process, which is snake_case. If you want to compare bodies, compare the result of doing builder.toJSON() with incoming objects from Discord, they'll match in format and structure.