No need to reverse the order of mixin conditions

Each compile/load compounds a new mixin condition at the end, and
the most inner error is handled first--so the mixin conditions
in a compound condition is ordered from inner to outer, which is
what we want to see in general.
A couple of macro fixes

- Allow unnamed macro object
- Fix bug in define-compiler-macro (It is still unhygienic; need to
address it)
Build fix regarding srfis.scm