Fix a bug with the scheduler and destructor order

The PausibleIdleCallback must have some handle into the event loop, and because
struct destructors are run in order of top-to-bottom in order of fields, this
meant that the event loop was getting destroyed before the idle callback was
getting destroyed.

I can't confirm that this fixes a problem in how we use libuv, but it does
semantically fix a problem for usage with other event loops.
Implement a basic event loop built on LittleLock

It's not guaranteed that there will always be an event loop to run, and this
implementation will serve as an incredibly basic one which does not provide any
I/O, but allows the scheduler to still run.

cc #9128
Handle weak symbols specially in the compiler

This style of symbol requires special attention by the compiler, and new ones
are coming down the pipe. Instead of relying on passing some weird linker flags
to the OSX linker, instead of having to always remember to do this, instead
handle weak symbols explicitly during linking (to tell OSX to look them up
dynamically)

The actual handling of these symbols is not yet performed (with the weak_linkage
attribute), that's coming soon!
Make some more rt components public

Primarily this makes the Scheduler and all of its related interfaces public. The
reason for doing this is that currently any extern event loops had no access to
the scheduler at all. This allows third-party event loops to manipulate the
scheduler, along with allowing the uv event loop to live inside of its own
crate.
Move rust's uv implementation to its own crate

There are a few reasons that this is a desirable move to take:

1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable

Here's a quick summary of the points of this pull request which make this
possible:

* Three new lang items were introduced: event_loop, event_loop_factory, and
  external_event_loop_factory. These three items aren't lang items in the sense
  of all other ones. Instead, two factory items use the event_loop item to
  generate a unique symbol which the factory will be called. The idea of a
  "factory" is to define a function which can be called with no arguments and
  will return the new event loop as a trait object. This "factory symbol" is a
  weak symbol referenced in libstd. If the symbol is null, then a basic event
  loop with no I/O support is provided, and otherwise the factory is used to
  generate a new event loop (when requested).

  There are a few reasons for doing this. First is that this enforces that an
  event loop implementation is only valid against the exact definition of the
  event loop trait. The symbol name for the event loop factory will change
  based on the crate that it's in (along with the version of the crate), and it
  should also change if the trait itself is modified.

  Finally, this is all done in a lazy fashion so the event loop doesn't have to
  be defined by any crate at all. If at runtime there is no event loop factory
  (for example you didn't link the rustuv crate), then the basic event loop with
  no I/O will be used to allow the scheduler to make progress.

* The name of the event loop factory is encoded into the metadata of the crate
  that it was defined in.

* When building an executable, then the rustuv crate will be linked by default
  (providing a default implementation of the event loop) via a similar method to
  injecting a dependency on libstd. This is currently the only location where
  the rustuv crate is ever linked.

* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
  implicitly linking to rustuv by default
Remove the 'callback_ms' function from EventLoop

This is a peculiar function to require event loops to implement, and it's only
used in one spot during tests right now. Instead, a possibly more robust apis
for timers should be used rather than requiring all event loops to implement a
curious-looking function.