Intro redux

Because my '30 minute intro' was originally a blog post, the tone was a bit too light. It also was written a long time ago, and deserves a bit of a refresher for modern Rust. now that my work on the Guide is wrapping up, I want to give it a quick re-write as well.

This is not yet done, but I'm submitting it for feedback so far. I'd really like some comments on the ownership part in particular, which gets lower level than before, but is not strictly 100% accurate. Trying to strike a balance.

In general, I'm not sure I go into enough detail for those without systems experience, but am afraid of too much detail for those that do.

Rendered view: https://github.com/steveklabnik/rust/blob/intro_redux/src/doc/intro.md

/cc @wycats @nikomatsakis @brson etc
This section seems to be motivating how Rust avoids data races, but nothing below here is actually at risk of a data race, since there is no mutation. I don't know what can be changed to make it work better, maybe it could just be something like

```rust
fn main() {
     let mut numbers = vec![1, 2, 3];
     for i in range(0, 10) {
          spawn(proc() {
              for j in range(0, 3) { numbers[j] += 1 }
          })
     }
}
```

which is illegal due to ownership (i.e. only one thread can have access to `numbers` at a time), and then it is still illegal with shared memory via `Arc` due to not being able to mutate a `&int`. And then the last step would be adding in a mutex, which does allow mutation, but is *not* unsynchronised.

On that point, this definition needs to mention that "at least one is unsynchronised" or "non-atomic", since concurrent mutation is legal via atomic instructions or with mutex-protected data. Various definitions:

-  http://en.wikipedia.org/wiki/Race_condition#C.2B.2B
- http://docs.oracle.com/cd/E19205-01/820-0619/geojs/index.html
- http://blog.regehr.org/archives/490