Derive state from extensions

[RedbackThomson]

Description of your changes

Related to https://github.com/upbound/up/issues/487

Refactor the code for deriving state using the extensions created as part of https://github.com/upbound/up/pull/491

The logic for deriving the state is now:

1. Load the current context, if none found then go to Cloud root navigation
2. Load the extensions a. If cloud space extension exists, call DeriveExistingCloudState b. If disconnected space extension exists, call DeriveExistingDisconnectedState c. If no extension exists, or extension invalid, call DeriveNewState

Each of the DeriveExisting*State methods uses the metadata from the extension to load the Space{} struct for their navigation state.

In order to get disconnected spaces working, Space{} now stores HubContext which is a pointer to the context in the current kubeconfig that points at the hub directly. When building a group kubeconfig for a Space{} which defines HubContext, we copy the values from the hub context cluster and hub context auth info instead of using the ingress.

NOTE: This PR does not re-use the hub cluster or authinfo. It will still create new upbound cluster and authoinfo every time a user runs up ctx - simply copying the values over. Re-using it is for a another PR.

I have:

• [x] Read and followed Upbound's contribution process.
• [x] Run make reviewable to ensure this PR is ready for review.
• [ ] Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested

• New unit tests for all of the new Derive* methods
• Updated unit tests for all of the Accept methods to match the new hub/ingress logic