It's clear that there are many different flavors of Ingress; enough so that it
is not tenable for our team to implement a specific solution for each type.
In addition to the problem that the quantity of flavors is an issue, it's also
possible that specific flavors of Ingress could require multiple resources as
an input in order for a plugin to produce a correct output for a desired
destination flavor.

For example, we have seen Traefik used by AKS, as presented by an early user.
There were two resources that might have been necessary to use as inputs in
order for us to write a plugin that could produce a Route. I think they were
called "IngressRoute" and "Middleware".

The actual way this ended up getting addressed was by blocking the Traefik
related resources from being created (either via whiteout during transform
or by removing them from the kustomization.yml file), and then recreating
the Route on the destination cluster manually.

Some questions raised while the problem was brainstormed:

• Is it possible to write a traefik specific plugin that has support for specific
  destination ingress flavors or even platforms?

Theoretical cmds:

`crane transform --from-platform=aks --to-platform=ocp`

# Upstream minded
`crane transform --from-platform=ocp --to-platform=eks`

Would necessitate support at the plugin API level to pass in src/dest platforms
and the plugins would make sense of what exactly it means to do with the input
and output.

As some final thoughts, there is a relatively finite amount of platforms that
we generally care about, and it's probably true that they also use a relatively
finite amount or standard Ingress flavor per platform. I.E. maybe AKS just uses
Traefik, and EKS uses something else, so it's actually OK for us to implement
the plugins for the platforms that we care about.

Goal for this spike is an enhancement that explores the problem, and addresses
the fact that this is something that's difficult to solve by just writing a
specific solution for each flavor, since there are so many. Looking for a
proposed path forwards for crane cli, and one that takes into account our
eventual suport for non-OCP source platforms in RHO.