Porch: enhancements to support building controllers

[liamfallon]

Original issue URL: kptdev/kpt#3452
Original issue user: https://github.com/johnbelamaric
Original issue created at: 2022-08-10T18:57:47Z
Original issue last updated at: 2022-11-15T22:55:44Z
Original issue body: For Nephio, the plan is to build controllers that use Porch as a southbound API. That is, we want controllers that operate on top of Porch - analogous to the UI operating on top of Porch, but an automation instead.

I build a proof-of-concept controller here: https://github.com/nephio-project/nephio-controller-poc. During that process I found a few improvements that would make the process simpler.

• Provide a public typed Porch API client. The current one is internal, I ended up copying and adapting it as well as creating some utility functions to more easily mutate PackageRevisionResources. Or, is it sufficient to AddToScheme? I wasn't sure with an aggregated API.
• Make it easy for controllers to leverage the fn runner (I didn't try this). Right now, the controller performs very specific mutations on the package. However, since the controller itself is driven by a resource spec, there is no reason that we can't allow that resource to identify functions to execute. This effectively expands our "orchestrator" from the kpt CLI client and basic Porch API, to a something that can be programatically accessed. Another way to think about this is to allow the external (to the package) controller operate on the package the same way a user would. A user may decide to imperatively execute a function against a package. I want my controller to be able to do that too - except it's actually declarative, just not declaratively built into the package, but rather into my controller resource. It's a slight shift in thinking so something worth discussion.
• Support annotations, ownerRefs, finalizers on PackageRevisions. To make the controller really work, I need ownerRefs. I need to be able to identify the packages revisions I manage so I can prune properly, for example. (Support metadata fields on packagerevision resources kptdev/kpt#3550)
• Support proper PackageRevision deletion. I am not sure this is working. I tried deleting a package revision from the UI and it disappeared from the UI but not from the repo.
• A "function development mode" where the function runner Pods have imagePullPolicy: Always would be nice so during function dev I don't have to retag and update the package, etc.
• Ways to manage the flow through the lifecycle (#3455)

There are probably more and I will add to this issue as I recall them or they surface.

Original issue comments: