Rename provider virtualworkspace to apiexport and add some docs

[embik]

Summary

I realized that virtualworkspace is a problematic name, given that there are other VWs with different semantics than the APIExport one (e.g. the initializingworkspaces one). Thus, I'm proposing to rename the provider for clarity.

In addition, I've added some light documentation so that the pkg.go.dev page for the provider looks a bit nicer and gives some hints.

What Type of PR Is This?

/kind documentation
/kind api-change

Related Issue(s)

Fixes #

Release Notes

Rename existing `virtualworkspace` provider to `apiexport`

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from embik. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[sttts]

How do other VW differ. We should not a different provider for each. Or at least a largely shared code base.

[embik]

How do other VW differ. We should not a different provider for each. Or at least a largely shared code base.

In the initializingworkspaces virtual workspace, the wildcard endpoint only lists LogicalCluster objects, and you have full/unrestricted access to specific logical clusters while they are still initializing. But that means each cluster will potentially be different (i.e. have its own REST mapper), with different already registered APIs, etc.

I agree that code should largely be shared, but I suspect that the slightly different semantics of VWs will force writing your own provider unless you 1:1 implement e.g. the APIExport VW semantics.