Add KptFileGVK to expose typed GVK information for Kptfile

[justinsb]

More ergonomic than a set of strings.

[yuwenma]

What's our long term plan about the Kptfile schema @mortent @droot? I think kpt should import the Kptfile schema from kpt-functions-sdk, so as users and other tools which use the Kptfile schema do not need to import it from Kpt, and this can avoid expected Kpt exposure and dependent loop problems. For example, the go SDK also needs to use the Kptfile schema and it imports from the kpt-functions-sdk/go/api. This change could potentially make the go sdk incompatible with the kpt fn.

This is not a blocker for this PR. I can pull the change to the kpt-functions-sdk this time. But I'm a little bit worried that the go sdk and kpt could be out of sync if we only make the change on the kpt side and not converge the Kptfile schema.

[mortent]

@yuwenma Why does the kpt-functions-sdk have a copy of the Kptfile type? It seems like the kpt repo would be the natural place have it and the sdk would import it.

[yuwenma]

I don't know the exact legacy reasons, but I think it makes sense for 2 reasons

1. Users who need to use the Kptfile type (i.e. to write their own kptfile relevant functions), they can import from go-sdk and do not need to import the entire kpt pkg.
2. kpt, as a CLI, is not designed for importing purpose so it should not worry too much about supporting its dependants.

It seems like the kpt repo would be the natural place have it and the sdk would import it.

I see kpt/porch has imported go/fn in several places. e.g. porch function wrapper main.go, porch builtin function runtime, which is aligned with the library dependencies I described above. And because of that, I don't think sdk can then import kpt/porch.