Support form url encoding

[iamdanfox]

Before this PR

The OAuth2 spec allows people to send data in the body as long as it is encoded sent with content type application/x-www-form-urlencoded.

https://tools.ietf.org/html/rfc6749#section-3.2

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
     &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

We have no intention of supporting this encoding as a way of defining conjure APIs, but I'd like people to use dialogue to make calls to MP, which requires this. cc @pkoenig10

After this PR

==COMMIT_MSG==
The BodySerDe#formUrlEncodingSerializer can be used to send application/x-www-form-urlencoded data (e.g. for OAuth2 endpoints).
==COMMIT_MSG==

Possible downsides?

• it muddies up the nice BodySerDe interface a bit.

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

The BodySerDe#formUrlEncodingSerializer can be used to send application/x-www-form-urlencoded data (e.g. for OAuth2 endpoints).

Check the box to generate changelog(s)

• Generate changelog entry

[carterkozak]

I'm not sure I understand why this should live in dialogue instead of the projects that intend to use it or a separate utility library.

I'm not convinced that map<str,str> is the ideal data type in this case. If there are numeric values do we expect consumers to effectively serialize those into strings prior to passing data through this serializer? What about collections of values like query parameters?

[iamdanfox]

Closing out because I think the URLEncoder.encode is pretty non-scary to use internally.