connect: intentions are now managed as a new config entry kind "service-intentions"

[rboyer]

• Upgrade the ConfigEntry.ListAll RPC to be kind-aware so that older
  copies of consul will not see new config entries it doesn't understand
  replicate down.

• Add shim conversion code so that the old API/CLI method of interacting
  with intentions will continue to work so long as none of these are
  edited via config entry endpoints. Almost all of the read-only APIs will
  continue to function indefinitely.

• Add new APIs that operate on individual intentions without IDs so that
  the UI doesn't need to implement CAS operations.

• Add a new serf feature flag indicating support for
  intentions-as-config-entries.

• The old line-item intentions way of interacting with the state store
  will transparently flip between the legacy memdb table and the config
  entry representations so that readers will never see a hiccup during
  migration where the results are incomplete. It uses a piece of system
  metadata to control the flip.

• The primary datacenter will begin migrating intentions into config
  entries on startup once all servers in the datacenter are on a version
  of Consul with the intentions-as-config-entries feature flag. When it is
  complete the old state store representations will be cleared. We also
  record a piece of system metadata indicating this has occurred. We use
  this metadata to skip ALL of this code the next time the leader starts
  up.

• The secondary datacenters continue to run the old intentions
  replicator until all servers in the secondary DC and primary DC support
  intentions-as-config-entries (via serf flag). Once this condition it met
  the old intentions replicator ceases.

• The secondary datacenters replicate the new config entries as they are
  migrated in the primary. When they detect that the primary has zeroed
  it's old state store table it waits until all config entries up to that
  point are replicated and then zeroes its own copy of the old state store
  table. We also record a piece of system metadata indicating this has
  occurred. We use this metadata to skip ALL of this code the next time
  the leader starts up.

[freddygv]

assuming nothing comes up in the integration tests run