Don't Panic: Remove main panic

In our example, we `panic` in `main` instead of the function `foo`. The
point that this was demonstrating was that the caller of the function
has the choice of panicking rather than `foo` itself.

Unfortunately, this causes confusion for readers modeling their `main()`
after this code, because the "good" example still panics.

This reduces confusion here by having `main` handle the `error` with an
`os.Exit`.

Note that this moves argument handling into `foo` because placing it in
`main` is not very testable.

style.md

@@ -1077,40 +1077,33 @@ allow the caller to decide how to handle it.
 <tr><td>
 
 ```go
-func foo(bar string) {
-  if len(bar) == 0 {
-    panic("bar must not be empty")
+func foo(args []string) {
+  if len(args) == 0 {
+    panic("an argument is required")
   }
   // ...
 }
 
 func main() {
-  if len(os.Args) != 2 {
-    fmt.Println("USAGE: foo <bar>")
-    os.Exit(1)
-  }
-  foo(os.Args[1])
+  foo(os.Args[1:])
 }
 ```
 
 </td><td>
 
 ```go
-func foo(bar string) error {
-  if len(bar) == 0 {
-    return errors.New("bar must not be empty")
+func foo(args []string) error {
+  if len(args) == 0 {
+    return errors.New("an argument is required")
   }
   // ...
   return nil
 }
 
 func main() {
-  if len(os.Args) != 2 {
-    fmt.Println("USAGE: foo <bar>")
-    os.Exit(1)
-  }
   if err := foo(os.Args[1]); err != nil {
-    panic(err)
+    fmt.Fprintln(os.Stderr, err)
+    os.Exit(1)
   }
 }
 ```