[Relay] Support 'external codegen targets'.

[mbs-octoml]

(Part of Collage, https://github.com/apache/tvm-rfcs/blob/main/rfcs/0062-collage.md)

This change prepares the target handling machinery to support
'external codegen' targets in addition to 'regular' targets. This allows us
to configure the build with Collage as follows:

    host_target = tvm.target.Target("llvm")
    targets = [tvm.target.Target("cuda", host_target),
               tvm.target.Target("cutlass", host_target),
               tvm.target.Target("cudnn", host_target)]
    with tvm.transform.PassContext(...):
        exe = tvm.relay.vm.compile(module, target=targets)

Four changes are required:

1. I introduce four new target kinds for the external codegens currently supported
   by Collage ("tensorrt", "cutlass", "cudnn" and "cublas"). Others can be added as
   they are vetted for use by Collage. These are given a device type matching the
   external codegen's assumption (ie just CUDA currently), and given a target kind
   attribute "is_external_codegen" of True. The latter is needed by Collage to signal
   the target kind name represents an external codegen 'compiler' name.
2. I introduce the binary relation Target::IsExternalCodegenFor so that
   'external codegen' targets can be related back to the 'regular' targets
   they are implicitly using in their codegen.
3. I rework the VMCompiler and BuildModule interfaces to accept an Array of
   'raw targets' instead of a Map<Integer, Target>. This more general representation
   is needed because we may now have multiple targets of the same device type
   active simultaneously. I add new static methods on the Python Target to
   convert to this form in a way that mimics check_and_update_host_consist.
4. I rework CompilationConfig to work from Array directly, to not depend
   on the host_target argument (since dealt with adequately on the Python side),
   and to understand that if we have two targets for the same device type the
   non-external codegen target takes precedence.

The change to CompilationConfig seems neutral with respect to the recent
discussions on compilation configuration representation and tvmc.

I've made sure to not expose CompilationConfig in any core APIs, preferring
the more neutral Array<Target> instead.

I made a few attempts to remove Target.check_and_update_host_const entirely in
favor of using CompilationConfig as the definitive target handling choke point but
backed out each time due to difficulties supporting the existing Python code.

[Lunderberg]

I think it makes sense to me, though I'll need to chew it over a bit more. I have some questions above, mostly about how the external target definitions would be used, and which sets of targets are allowed.

[mbs-octoml]

Hey thanks Eric. PTAL. Note the Hexagon special case in CompliationConfigNode::Init, which I transliterated from the AOT build. Would be good to check that's the Right Thing to Do.

[mbs-octoml]

Last call?

[jwfromm]

Very nicely done and a pretty slick API for external targets. Thanks @mbs-octoml!

[csullivan]

Thanks @mbs-octoml, LGTM regarding the handling for Hexagon as a host target in CompilationConfigNode::Init -- reads to me as equivalent and the AOT tests pass on hardware.

[csullivan]

Thanks @mbs-octoml, @Lunderberg, @jwfromm, this is merged!