Better serialization

[ob-stripe]

Summary of changes:

• Renamed ParameterBuilder to FormEncoder
• Greatly simplified the form-encoding logic by replacing a bunch of reflection and unsafe casts with pattern matching
• New utility class StringUtils with one new method:
  • ToSnakeCase(): converts strings from CamelCase to snake_case. This is used for Expand* properties on services, to convert from the service's property name (e.g. ExpandFooBar) to the Stripe property name (e.g. foo_bar).
• New extension method on BaseOptions:
  • ToQueryString(): returns a form-encoded query string containing all of the parameters in the options class, including the ones set in the ExtraParams dictionary and the Expand list.
• New extension method on Service:
  • Expansions(): returns a list of strings with the properties to expand. E.g. if the service has three properties ExpandFoo, ExpandBar and ExpandAllTheThings and the last two are set to true, the method will return a list containing "bar" and "all_the_things".
• Greatly simplified the existing extension method ApplyAllParameters() on Service
• Moved the files that were at the root of Services/ to either Services/_base (for base classes meant to be derived from) or Services/_common (for options classes that can be used as-is and that are not specific to a single service)
• Updated tests to be consistent with the changes above

Since we have pretty good test coverage for encoding (and I've added a few more tests) I'm fairly confident that I haven't broken anything, but there are a few changes:

• square brackets characters are no longer URL-encoded. This is consistent with most of our other clients and is meant to make the query strings easier to read by humans (since the server doesn't care one way or the other)
• expand parameters are now encoded with integer indices (e.g. expand[0]=foo&expand[1]=bar). Previously, they were encoded without indices (expand[]=foo&expand[]=bar). This was inconsistent with the way regular lists are encoded. Now all lists are encoded the same way (I've also checked that the server accepts this).

I'm targeting a new integration-v23 branch despite the fact that there are no breaking changes in this PR, since I have a few more updates planned. The breaking changes should be fairly limited this time around though!

[remi-stripe]

This looks good to me and I like how it was re-organized! As usual though this is core to the library and I'm less comfortable approving myself so please be careful and all that :)

[ob-stripe]

r? @brandur-stripe @remi-stripe
cc @stripe/api-libraries

[brandur-stripe]

Wow, awesome work here OB! Love the clarity, and love how many new tests are coming in for these primitives :)

Didn't find anything objectionable in here. Maybe one thing I'd be a little careful about is getting to overzealous with extension methods — they're super cool, but there is a clarity trade-off in that it's immediately clear where StringUtils.ToSnakeCase comes from, but not where str.ToSnakeCase comes from without going up to check the imports.

It's not a big deal in C# because probably everyone is using an IDE of some sort anyway, but something to think about, especially in instances where the extension methods aren't expected to have a whole lot of use, so you don't really need the short-hand that badly anyway.

LGTM.

[ob-stripe]

but there is a clarity trade-off in that it's immediately clear where StringUtils.ToSnakeCase comes from, but not where str.ToSnakeCase comes from without going up to check the imports.

Great point, I did get a little carried away with the extension methods :) Looking at Newtonsoft.Json's source code, they do have a static method named exactly StringUtils.ToSnakeCase.