`triton profile set NAME` and `TRITON_PROFILE` interaction is confusing

(From a conversation with @STRML on #joyent IRC.)

How a triton invocation determines the profile to use can be confusing. If you use the suggested eval $(triton env) technique to setup one's env for docker usage, one may not realize that the TRITON_PROFILE envvar is being set to the current profile. Subsequent attempts to "set" one's profile with triton profile set NAME will report success, but really you won't get that profile for triton commands because the TRITON_PROFILE envvar will win.

Further possible confusion is how the "env" profile works. The "env" profile automatically exists if one has SDC_ and/or TRITON_{URL|ACCOUNT|...} envvars set. So, in the case above one might not have had an "env" profile in triton profile list ... until eval $(triton env) was run. Now there is this new "env" profile. Are the SDC_ envvars now used by triton commands? The answer is: only if the "env" profile is the current one.

Suggested changes:

• triton profile set-current (and its set shortcut) are misleading. They are really about setting the default profile (if neither of a -p NAME top-level option or TRITON_PROFILE envvar are used to explicitly choose the profile). We should change to the set-default name and have hidden set and set-current aliases for bwcompat (which we can remove at some later major rev).
• The docs in all of triton profile, triton env -h, and triton profile set-default -h should clarify how a profile is selected.
• triton profile set-default FOO should emit a warning on stderr if it notices that TRITON_PROFILE is set or if -p NAME top-level opt is used.

Start by inspecting the triton profile set-current and set commands, then read the help output for triton profile, triton env -h, and triton profile set-default -h. Done means the default-profile behavior and precedence of -p NAME and TRITON_PROFILE are clear, compatibility aliases remain available, and set-default warns when an override is active.