feat: use both project and user API token and populate default org id and projectid

[aayushrangwala]

#265

[cprivitere]

This seems to run much slower now than the current release. I assume that's due to it doing much more searching?

[cprivitere]

So just tested this out, it's nearly 0 delay while waiting for it get your project id and org on the current main branch, and about 3-4 seconds on this new version. If we're ok with that, we are good to go.

[ctreatma]

IMO we should stick with loading the current user first so that, if we were given a user token, we avoid loading more projects than necessary or making multiple paginated calls to the projects endpoint. What is the response and/or error that comes back if we try to run c.UserService.FindCurrentUser(context.Background()).Include(include).Exclude(exclude).Execute() with a project token? Is there something in the response/error that we can use to decide that the token might be a project token?

[displague]

The description of #265 had an approach in mind

[ctreatma]

This PR is already largely following the steps in the issue description. I still prefer adding project API support in a way that does not add latency to user token initialization, but adding the 2-project limit described in that issue to this PR would at least reduce the added latency.

[ctreatma]

@chris pointed out that a user might only have 1 project, in which case metal init would treat their token as a project token instead of a user token; the token type doesn't have any impact outside of the init command, though, so which endpoint we try to load first is largely a philosophical issue. I leave the decision up to the contributor as to whether we should remove auto-pagination from getProjectsOK or load the current user endpoint first and then try projects if current user 403s.

[displague]

I left a nitpick about the output which seems to be more of a debugging aid rather than necessary or helpful to end-users. https://github.com/equinix/metal-cli/pull/325/files#r1471550998

If this text were accompanied by a full list of organization ids that the key could access, it may be more useful. I would want to defer that work to accompany investigation into TUI or more interactive prompting tools (with name based autocompletes or console drop downs, for example).

Otherwise, this has been tested for a User API Key and Project API key. In my User testing I had a null project id default for some tests and a defined id - worked fine under both conditions.