chore: refactor dataplane components (client, synchronizer, and parser)

[shaneutt]

What this PR does / why we need it:

This significantly refactors the internal/dataplane code the original motivation was to make it easier to later add options to parser for #1492.

Most notably this PR splits what was previous called the Proxy interface, which had both the aspects of a high level data-plane API client and a synchronization server for the data-plane. It's responsibilities are now split into dataplane.KongClient and dataplane.Synchronizer and while the diff is large, the code has mainly just been moved around and the resulting objects are much easier to read and understand.

High level refactoring notes:

• the Proxy interface no longer exists, it's concerns have been separated into a dataplane.Client and a dataplane.Synchronizer
• the dataplane.KongClient is now responsible for updates to the dataplane: internal/dataplane/sendconfig/common_workflows.go has been consumed
• internal/dataplane/parser is now an object which can be configured to allow attributes to affect runtime logic instead of having to continually add more function parameters and feed them down the call chain, this will make it easier to add options that are specific to some resource types, or otherwise influence parsing with lighter weight PRs
• translate code (and tests) now have their own files to help make it easier to locate the specific object translator you're looking for
• the data-plane has in general become more abstract: higher level components are more able to treat the data-plane as opaque than before, and not have to think about Kong specific semantics. We don't have current plans to support any data-plane APIs other than the Kong Admin API, but this change will inherently make it easier to support alternative APIs in the future.

Which issue this PR fixes

Resolves #2295

Special notes for your reviewer:

No user facing changes, and despite the fact that the diff looks large functionality was just moved not added.

[rainest]

Some minor file name bikeshedding and a dead link.

Can you clarify the "make it easier to later add options to parser" refactor/indicate what we should look at that isn't just reorganization? What did we do before (I think this is "add new parameters to NewCacheBasedProxyWithStagger() and friends) and how do we handle that after this change?

[shaneutt]

Can you clarify the "make it easier to later add options to parser" refactor/indicate what we should look at that isn't just reorganization? What did we do before (I think this is "add new parameters to NewCacheBasedProxyWithStagger() and friends) and how do we handle that after this change?

Before options were passed as function parameters and would need to be passed through several layers of function calls (options like the logger for instance). Now the parser is a struct with the logger (again, for instance) as an attribute. Future iterations will now be able to feed options from the dataplane.KongClient to the parser as object attributes that can be accessed in methods.

[rainest]

A more concrete condensed pseudocode example would still help understanding the refactor better, but eh, looks reasonable enough, I suppose that can wait til a PR for #1492.