[phobos] improved module cycle detection algorithm finds existing cycle in phobos, what to do?

[Steve Schveighoffer]

OK, so I've built a correct cycle detection algorithm (see 
http://d.puremagic.com/issues/show_bug.cgi?id=4384), that runs in O(n^2) time, 
just like the current, and uses as little stack space as possible (on the order 
of O(n^2) but with a lot of heuristics).  It also prints out the cycle that was 
detected.

I would check it in, but it found a cycle in phobos.  Here is the printout (note 
that this isn't necessarly the smallest cycle, just a cycle):

Cyclic dependency in module std.encoding 
imported from std.string  
imported from std.dateparse  
imported from std.date  
imported from std.file  
imported from std.stdio  
imported from std.functional  
imported from std.range  
imported from std.exception  
imported from std.conv  
imported from std.array  
imported from std.algorithm  
imported from std.random * 
imported from std.range  
imported from std.exception  
imported from std.conv  
imported from std.array  
imported from std.algorithm  
imported from std.string  
imported from std.encoding * 
object.Exception: Aborting due to cycle between (*) elements with module 
ctors/dtors

So what this is saying, is std.encoding indirectly imports std.random, which 
indirectly imports std.encoding, and both of these modules contain shared module 
ctors.  I manually verified the cycle path, and that shared ctors exist, so it 
is a real cycle.

My problem now is, I want to commit this, but as soon as I do, it will break 
phobos.

So what to do?

Note that this is the first cycle detected from building make -f posix.mak 
unittest.  There may be more, I can post them all here if need be.

-Steve