Remove Settings.settingsBuilder.

[jpountz]

We have both Settings.settingsBuilder and Settings.builder that do exactly
the same thing, so we should keep only one. I kept Settings.builder since it
has my preference but also it is the one that we use in examples of the Java API.

[nik9000]

Settings.builder

[jpountz]

Note to reviewers: the change is purely mechanical.

[nik9000]

We probably should never import static Strings.builder because Settings.builder() is much more readable than builder(). It'd be fairly simple to add a check for that to the regexes we run during checkstyle. I'd probably do that - either temporarily to find and remove them all or permanently with a helpful message telling people to use Settings.builder.

BTW, I love static imports when the static methods are named appropriately, but I also love when static methods can be named in such a way that it is nicer not to statically import them. So, personally, I like that we don't have a hard and fast rule against static imports. The SETTINGS above this are a super great use of static imports.

[nik9000]

In the name of moving forward, LGTM. but we really really shouldn't be statically importing Settings.builder because it makes the call sites confusing. I'm fine with merging this as is and creating another PR myself to remove those imports if you want.

[dadoonet]

++ Thanks for doing this Adrien! This always confuses me when my IDE propose the 2 methods... :)

[jpountz]

@nik9000 I agree these static imports are not nice. I pushed a new commit.

[nik9000]

LGTM