Add Crossplane package language server xpls to up as a subcommand

[tnthornton]

Description of your changes

We've found that a common pain point for package authors is the lack of feedback they receive during the author loop (write yaml -> test if yaml is valid -> write more yaml). In order to make initial strides to address that pain and lower the barrier to entry for new authors into the package space, we're adding a Crossplane package (xpkg) language server to the up CLI.

The initial alpha release of xpls includes the following features:

• crossplane.yaml validations
  • validates that the defined package (name and version) exist locally. Returns an error diagnostic if validation fails.
  • validates that the defined package type matches the package itself. Returns an error diagnostic if validation fails. For example, if the author specifies:

    spec:
        dependsOn:
            - configuration: provider-aws
               version: "v0.20.0"

    an error diagnostic will be returned due to provider-aws being a Provider package, not a Configuration package.
• validation of composed resource definitions per the resource's CRD's openAPIV3Schema
  • a differentiating feature from the general Kubernetes plugin (in VSCode) is that Compositions have embedded resources, unfortunately, the CRD for a Composition defines spec.resources[*].base as a general object. xpls solves this by using the openAPIV3Schema for the corresponding composed resource to validate its fields.
  • for the alpha release, xpls will highlight areas where the current definition does not meet the spec requirements.
• establishing a local cache for external package contents

In addition to the above features for xpls, this changeset includes a new xpkg subcommand dep.
Using up xpkg dep you can do the following:

• up xpkg dep invoked in a current package repo will install the package dependencies defined in the package's crossplane.yaml
• up xpkg dep <package-name> will install the supplied package into the local cache. If the command is invoked within a package repo the supplied package will be added to the crossplane.yaml for the package.
  Example invocations:

  # this invocation will add the latest version of crossplane/provider-aws to the local cache
  up xpkg dep crossplane/provider-aws
  
  # this invocation will add specifically version v0.20.0 of crossplane/provider-aws to the local cache
  up xpkg dep crossplane/provider-aws@v0.20.0

• up xpkg dep -c will clear the local cache

I have:

• Read and followed Upbound's contribution process.
• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

Beyond unit tests, the code was tested performing validations against a repo that contains an xpkg modeled after getting-started-with-aws as well as various internally authored packages.

[hasheddan]

A few comments, but otherwise this is looking pretty good (almost all of this has already undergone review) -- awesome work here @tnthornton!

[hasheddan]

I believe these references to up-ls need to be updated 👍🏻

[hasheddan]

There are a few more throughout this doc as well

[hasheddan]

I don't think we want the DEBUG and GO_BUILDFLAGS set here anymore. We also likely shouldn't be overriding GO_PKG_DIR because that has impact on how we do caching as well (though we can work around it if absolutely necessary). I believe the GO_PKG_DIR bit is to make the install go to the right location -- I wonder if we could update guidance for development to just build and then make sure it is in your PATH?

[tnthornton]

Sounds good.

We also likely shouldn't be overriding GO_PKG_DIR because that has impact on how we do caching as well

I believe I added that awhile back for two reasons:

1. to have the output of go install end up in the right location
2. we were duplicating efforts between the go mod cache and the .cache dir in up.

Overriding that location subverts the sandboxing in our builds, totally understand that, I just wanted to provide the extra context there for anyone else coming across these settings.

[hasheddan]

Guessing our guidance here will want to be updated to get this from the marketplace when it is available -- I could see that being a follow up if you prefer, and perhaps this section could be moved to local development documentation (rather than the docs from this dir that we sync to cloud.upbound.io/docs)

[tnthornton]

and perhaps this section could be moved to local development documentation

I think I'd prefer this path. Currently, publishing to the marketplace will be blocked by this PR getting merged so I'd rather not end up with a circular deployment dependency 😅 .