Introduce builders where appropriate

[andregasser]

There are cases where issuing a request using our client becomes a bit clunky. one example is when we want to post a status by calling the postStatus(...) method.

Example code taken from PostStatusWithMediaAttached.java in the sample-java collection:

// Post status with media attached
final StatusesMethods statusesMethods = new StatusesMethods(client);
final String statusText = "Status posting test";
final String inReplyToId = null;
final List<String> mediaIds = Collections.singletonList(mediaId);
final boolean sensitive = false;
final String spoilerText = "A castle";
final Visibility visibility = Visibility.Private;
statusesMethods.postStatus(statusText, inReplyToId, mediaIds, sensitive, spoilerText, visibility).execute();

The method signature of postStatus looks like this:

@JvmOverloads
@Throws(BigBoneRequestException::class)
fun postStatus(
    status: String, 
    inReplyToId: String?, 
    mediaIds: List<String>?, 
    sensitive: Boolean, 
    spoilerText: String?, 
    visibility: Status.Visibility = Status.Visibility.Public
): MastodonRequest<Status>

postStatus() uses the @JvmOverloads annotation. status and sensitive are non-nullable whereas the others are. So when we want to call this method from Java, we need to pass a value for inReplyToId even it is an optional field. This is because the amount of method overloads generated by @JvmOverloads is limited. By using a builder, we could avoid passing null values just to make the method call work. The whole call would look cleaner and be more readable:

final StatusesMethods statusesMethods = new StatusesMethods(client);
var status = Status.Builder("Status posting test")
    .addMediaId(mediaId)
    .sensitive(false)  // could be even left away if false is a default value
    .spoilerText("A castle")
    .visibility(Visibility.Private)
    .build()
statusesMethods.postStatus(status).execute();

Required attributes would go into the Builderconstructor, whereas optional arguments can be specified using builder methods.

But: Naming must be clarified, as Status is already used as a response entity from the Mastodon API...

[bocops]

I just commented in #124 that both editing an existing status, as well as deleting&redrafting a status, are actions that are similar to posting a status and could probably use a builder as well.

At least the delete&redraft action could probably even be solved using the same builder, by giving that a .fromStatus(status) method that fills necessary from the Status entity that was returned when deleting the old status.