[next] Investigate removing the ConfigProfiles.load method

[t1m0thyj]

I created the ConfigProfiles.load method when the "auth login" command was updated to use team config. We needed a way to load profile info, which didn't exist yet.

After the profile info API is created (#556), it should do everything that ConfigProfiles.load does, and much more. We may want to remove the method if it is no longer necessary.

[t1m0thyj]

Refactoring the "auth login" handler to use the new ProfileInfo API could be an opportunity to test the ProfileInfo API and better define its behavior for handling tokens.

Some relevant comments from #579:

• Can we accurately describe how a base profile's user, password, or token is merged with a service profile's user and password?
• Which arguments are returned by the ProfiInfo API?
• I am less interested in how it operates, and more interested in what the consumer should expect, for example:
  • Is a token NOT returned if a user & password are found in a service profile?
  • Do we return a token if the user & password for the service profile is inherited from a higher-level node in the JSON document?
  • Will we return all such arguments and expect the consumer to sort out token vs user & password?
• Do we need automated tests to confirm the expected behavior?