Maintain resources in a list.

[monopole]

Since kustomize started, resource order in the
output has been determined by a final sort, and
hasn't been influenced by the order implied by
resource file names, resource object names, or the
order declared in the resources and bases
fields of a kustomization file.

Beyond the final sort, order wasn't given much
thought, since a cluster is notionally an
unordered set of resource objects, and the apply
operation sends objects into the cluster to face an
unknowable set of race conditions involving custom
resource setup that controllers simply have to
deal with.

In practice, however, order matters - e.g.
Namespace "objects" must be applied first,
before objects can be applied "in" that namespace.

There have been proposals to allow different sorts
to replace the one built into kustomize, but the
new plugin system is supposed to be general enough
to allow a sorting transformer plugin, so users
can sort however they like via a plugin. However,
for that to be possible, resource order has to be
stable from transformation step to transformation step.
Moreover, the transformers themselves, which are
expressed as k8s resources, have to be maintained
in a specific order, as they are non-commutative.

This need for order makes the internal data
structure of kustomize, a map, much less
attractive from a code complexity point of view.

This PR replaces the core map with a list, a step
towards preserving resource order as specified in
kustomization files (related: #756 #821), as a
no-sort way to control ordering, and as a
necessary condition to allow transformer plugins.

Removing the heretofore far too mutable map is
also a necessary step to removing a map key hack
(a mutable ID key that holds prefix/suffix mods)
that, along with general map usage, has been
involved in many closed bugs but is still causing
pain (#316 #710 #800 #972 #1028 #1082 #1142).

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: monopole

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [monopole]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[damienr74]

Any reason not to modify this to t.Fatalf(...) since the other error is handled that way an this code is duplicated in every test that uses makeResAccumulator? You could completely remove the error return and just call Fatalf on error.

Not really that important, just code cleanup.

[monopole]

good catch, done.

[damienr74]

/lgtm