Improve handling of package context in subpackages

[liamfallon]

Describe your problem

When a kpt package contains a subpackage, the builtin KRM function "pkg_context" breaks if it is run on the base package. The current implementation of "pkg_context" adds a "package-context.yaml" file to all kpt packages and sub-packages with identical an identical "kind/version/name". The krm function adds a -package-context.yaml" containing a configmap with the name "kptfile.kpt.dev" to ALL packages and subpackages. This PR changes that builtin krm function to only add "package-context.yaml" to the root kpt package in the Package Revision.

When the first kpt package or subpackage in the PackageRevision is rendered in the mutation pipeline, it adds the ConfigMap called "kptfile.kpt.dev" to k8s. When the next kpt package or subpackage is rendered, the rendering fails because the ConfigMap called "kptfile.kpt.dev" already exists.

This PR in Porch does a naive fix. The path of the kptfile is checked and the "package-context.yaml" file is only added to the root kpt package.

We need to revisit how "package-context.yaml" works. The package-context idea is that there is a global ConfigMap called "kptfile.kpt.dev", which all krm functions can use. It looks like subpackages were not considered when this was implemented and we may need to think about whether we want a single ConfigMap covering all kpt packages in a hierarchy and/or have individual ConfigMaps at each node in the hierarchy. We also need to consider what teh scope of package context is at each level in the hierarchy.