Change field visibility and single-expression return syntax

[NoakPalander]

• Changed the visibility of
  dev.kord.rest.builder.interaction.OptionsBuilder.name, .description, .type from public to protected due to them serving no purpose as public from an API standpoint. E.g

guild.createApplicationCommand("...", "...") {
    string(name="some_name", description="some_description") { // obligatory fields
        this.name = "some_other_name" //  this line serves no purpose
        this.description = "some_other_description" // this line serves no purpose
        this.type = ApplicationCommandOptionType.String // this is already specified by the `string` choice-builder
    }
}

The reason for them not being private is due to BaseCommandOptionBuilder.toRequest and BaseChoiceBuilder.toRequest requiring access to these fields when returning an ApplicationCommandOption object.

• Changed the .toRequest functions to single expression return syntax
  Reduces some redundancy, e.g return type and unnecessary return keyword

[HopeBaron]

Hello! Thanks for your contribution
While I do agree that type should be private in order to eliminate unintended behavior, name and description should still be public, applying logic to your paramters becomes kind of annoying, some people would like to change name/description while they are building the command.

[NoakPalander]

Created a new commit. How would you feel about having the two remaining fields as nullable and default initialized. When applying "logic" to them one would still have to specify the fields and assign them empty strings as:

string("", "") {
    name = foo()
    description = bar()
}

while that could be changed to e.g

string { // name: String? = null
    name = foo()
}

Whilst still allowing the previous

string(name, description)

[HopeBaron]

Thanks for your question.
The fact that they are mandatory is that they are required.
it's required to have a name and description in the Discord system, they can't be null.
but Kord allows you to "edit" them before you send the final request.

what would be an appropriate representation of null in a parameter that is required? an empty string? some default string?
The type reflects the requirement by Discord as well, not only that of Kord's.

[NoakPalander]

I can see how that's be problematic. Anyhow, I pushed another commit, please review if it's suitable for a merge :)

[HopeBaron]

@NoakPalander sorry for the delay on the merge. can you make type public but make it a val instead?
this would allow the user to check for the argument type inside an OptionBuilder of an unknown type

[HopeBaron]

Thank you for your contribution! Hit us on Discord if you haven't!