Add the black Python code formatter

[LukeShu]

Description

It's silly how many code review comments are about formatting of Python code. Mechanical things like that are the job of computers, not human reviewers. For many years, there were many competing Python code formatters. However, in the last couple of years, the Python community has come to a realization that the Go community realized from the get-go: Agreement on the formatter is more important than the formatting itself. That even if the formatting isn't your favorite, that not having to have discussions about formatting is even better. So the Python community has standardized on the black formatter.

So adopt black the way we've adopted gofmt!

• The first 2 commits are addressing things to get them ready for black
• The 3rd commit is adding black in to our tooling, but not yet committing the results of running black
• The final commit is just running make format/black (running just make format would do this and a few other things too)

That last commit, while being machine-generated, is probably still worthy of decent scrutiny, to make sure it didn't move around a comment to where it's not near the code it's describing, or something funny like that.

I considered turning parts of black off, and only re-formatting things incrementally over time, so as to avoid merge-conflicts with current in-flight Python work. While tempting, there's still no good time to turn each thing on, so I figure it's better to just bite the bullet and get it over with rather than drawing it out over months.

Checklist

• I made sure to update CHANGELOG.md. - no applicable changes

  Remember, the CHANGELOG needs to mention:

  • Any new features
  • Any changes to our included version of Envoy
  • Any non-backward-compatible changes
  • Any deprecations

• This is unlikely to impact how Ambassador performs at scale.

  Remember, things that might have an impact at scale include:

  • Any significant changes in memory use that might require adjusting the memory limits
  • Any significant changes in CPU use that might require adjusting the CPU limits
  • Anything that might change how many replicas users should use
  • Changes that impact data-plane latency/scalability

• My change is adequately tested.

  Remember when considering testing:

  • Your change needs to be specifically covered by tests.
    • Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled.
  • You also need to make sure that the entire area being changed has adequate test coverage.
    • If existing tests don't actually cover the entire area being changed, add tests.
    • This applies even for aspects of the area that you're not changing – check the test coverage, and improve it if needed!
  • We should lean on the bulk of code being covered by unit tests, but...
  • ... an end-to-end test should cover the integration points

• I updated DEVELOPING.md with any any special dev tricks I had to use to work on this code efficiently. - no tricks (no new trucks, make lint is still the way to have formatting mistakes caught, and make format is still the way to fix them in and automated fashion)

• The changes in this PR have been reviewed for security concerns and adherence to security best practices.

[kflynn]

SO...

a. Ew. Wow. There are things I just hate about Black's choices here.
b. Having a standard is still better than having no standard. Ship it.