Refactor ClientConfigBuilder.build

[pileks]

This PR aims to refactor out all unnecessary elements of the client-config-builder package, and defined what I saw as a "legacy" config for the PolywrapClient.

Generally inspired by @krisbitney's comments on #1480 with some additional cleanup.

Remaining work:

• Figure out tests for the new ClientConfigBuilder now that it only outputs CoreClientConfig.

[cbrzn]

I am a bit confused with the legacy folder, at first, I guess this is temporary, but how the long-term solution would look like?

[cbrzn]

We should not test that the resolver works here but that it can be added/removed and the object will be as expected. The resolver itself can be tested in the client (If I understand things correctly)

[pileks]

Yup, that's my conclusion as well. However, CoreClientConfig only has an opaque resolver which cannot be tested structurally with something like shouldEqual.
I'm approaching this now by having the ClientConfigBuilder be able to "spit out" its _config object so that its structure can be tested.

[pileks]

I am a bit confused with the legacy folder, at first, I guess this is temporary, but how the long-term solution would look like?

I'm honestly not sure. It's not "legacy" per se, but it's there to support all the various forms of client config objects that we had in the past. The "non-legacy" approach is simply using ClientConfigBuilder, but allowing only that would break existing implementations of the PolywrapClient. I've therefore decided to bundle all of that up in a legacy folder so that we're aware that it's something that used to be done that way.