ls: prevent no-color build from complaining when COLORTERM is non-empty

As 257886 reports, if ls(1) is built with WITHOUT_LS_COLORS="YES", it
issues a warning whenever COLORTERM is non-empty. The warning is not
useful, so I thought to remove it, but as Ed pointed out, we may want
to have a way to determine whether a particular copy of ls has been
compiled with color support or not.

Therefore move the warnx() call to the getopt loop in
a WITHOUT_LS_COLORS build to fire when the user asks for colored output.

PR:		257886
Reported by:	Marko Turk
Reviewed by:	kevans

bin/ls/ls.c

@@ -105,9 +105,7 @@ static void	 traverse(int, char **, int);
 
 static const struct option long_opts[] =
 {
-#ifdef COLORLS
         {"color",       optional_argument,      NULL, COLOR_OPT},
-#endif
         {NULL,          no_argument,            NULL, 0}
 };
 
@@ -448,8 +446,8 @@ main(int argc, char *argv[])
 		case 'y':
 			f_samesort = 1;
 			break;
-#ifdef COLORLS
 		case COLOR_OPT:
+#ifdef COLORLS
 			if (optarg == NULL || do_color_always(optarg))
 				colorflag = COLORFLAG_ALWAYS;
 			else if (do_color_auto(optarg))
@@ -460,6 +458,8 @@ main(int argc, char *argv[])
 				errx(2, "unsupported --color value '%s' (must be always, auto, or never)",
 				    optarg);
 			break;
+#else
+			warnx("color support not compiled in");
 #endif
 		default:
 		case '?':
@@ -503,8 +503,6 @@ main(int argc, char *argv[])
 			f_color = 1;
 			explicitansi = true;
 		}
-#else
-		warnx("color support not compiled in");
 #endif /*COLORLS*/
 	}