make cm compile all depdencies, not just the first one that needs it

This wouldn't matter if the dependencies recorded in the dep file were
exactly the same as the files that are actually loaded when a file is
required. But in the case of lazy-require (or, more accurately, when
the cm-accomplice library is used), the dependencies in the dep files
can include things that are, in some cases, not actually
required. This is no problem for raco setup, since it looks at all of
the files anyway, but it can cause a particularly bad interaction with
DrRacket's online compilation facility.

For example say there is some file, e.g., mzscheme/main that is
required lazily. So when you edit a file in DrRacket, it will traverse
the requires and lets say it sees that the of mzscheme/main's
dependencies need to be compiled.  So it will compile that dependency,
and then the ormap in this commit will be shortcircuited, which will
cause CM to stop looking at dependencies and decide to compile
mzscheme/main. So DrRacket will compile mzscheme/main, and then
whatever other pending compiles were going on and DrRacket's online
check syntax will complete, but because the lazy require doesn't
triggered, mzscheme/main isn't actually loaded during compilation.

Now you make another edit to the buffer and the same thing happens
except this time it gets past that first dependency of mzscheme/main
because there is now a .zo file for it from the last go 'round. But
say there isn't one for the second dependency. So it compiles that
file and compiles mzscheme/main now for a second time, but still
doesn't look at the third and fourth (etc) dependencies of
mzscheme/main.

Overall, this means that the second time you edit you file in
DrRacket, it should have been quick for the expansion portion to
finish because, after all, everything has been compiled and should
have been cached in .zo files. But because of the short circuiting, it
the .zo files weren't actually created and so your second edit is also
slow to come back.

After this commit, because of the ormap, the second edit will be
faster.

One worry with this commit is that it might change something that
could cause raco setup to go slower. To test that, I applied only this
change to a fresh checkout and did a full build. I then deleted all zo
files in racket/share/pkgs and timed 'raco setup -D' twice (four times
total). Here are the timings I get. The version of the code that uses
ormap:

  % ... delete .zo files ...
  % time raco setup -D
  real    9m2.354s
  user    37m5.176s
  sys     4m14.963s
  % ... delete .zo files ...
  % time raco setup -D
  real    9m2.421s
  user    37m43.793s
  sys     4m23.111s

The version of the code that uses the change in this commit:

  % ... delete .zo files ...
  % time raco setup -D
  real    8m58.852s
  user    36m51.369s
  sys     4m13.633s
  % ... delete .zo files ...
  % time raco setup -D
  real    8m53.980s
  user    37m40.262s
  sys     4m23.692s

racket/collects/compiler/cm.rkt

@@ -668,7 +668,7 @@
               (trace-printf "newer src...")
               ;; If `sha1-only?', then `maybe-compile-zo' returns a #f or thunk:
               (maybe-compile-zo sha1-only? deps mode roots path orig-path read-src-syntax up-to-date collection-cache new-seen)]
-             [(ormap
+             [(ormap-strict
                (lambda (p)
                  (define ext? (external-dep? p))
                  (define d (collects-relative*->path (dep->encoded-path p) collection-cache))
@@ -704,6 +704,14 @@
       (begin (trace-printf "checking: ~a" orig-path)
              (do-check))))
 
+(define (ormap-strict f l)
+  (cond
+    [(null? l) #f]
+    [else
+     (define a (f (car l)))
+     (define b (ormap-strict f (cdr l)))
+     (or a b)]))
+
 (define (managed-compile-zo zo [read-src-syntax read-syntax] #:security-guard [security-guard #f])
   ((make-caching-managed-compile-zo read-src-syntax #:security-guard security-guard) zo))