Really unload object code when it is safe to do so (#8039)

The next major GC after an unloadObj() will do a traversal of the heap
to determine whether the object code can be removed from memory or
not.  We'll keep doing these until it is safe to remove the object
code.

In my experiments with GHCi, the objects get unloaded immediately,
which is a good sign: we're not accidentally holding on to any
references anywhere in the GHC data structures.

Changes relative to the patch earlier posted on the ticket:
 - fix two memory leaks discovered with Valgrind, after
   testing with tests/rts/linker_unload.c
Only add -O to C compilations if there was -O on the command line

In 1e2b3780ebc40d28cd0f029b90df102df09e6827 I changed the option
ordering for C compilations.  A side effect was that -optc options
came before the automatic -O we were adding, which made it so that the
-debug RTS was getting optimised when it shouldn't have been.

Perhaps we shouldn't have automatic -O options added to C
compilations.  But that might cause problems for build systems that
are relying on the current behaviour, so I've made a minor change
instead: now C optimisation level == Haskell optimisation level.
Comments only

This comment is no loger true
Update release notes for GHC 7.8
Remove DYNAMIC_GHC_PROGRAMS tests in the linker

The linker is usable even when GHCi is dynamically linked.  These
tests make the linker_unload test fail.
Strings and comments only: 'to to ' fixes

I'd still prefer if a native english speaker would check them.
Update email addresses