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?

The description of #265 had an approach in mind

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.

@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.