Support linking of rlib files in rustpkg
Fix indention
Add support for ARM thumb architecture
auto merge of #11700 : bharrisau/rust/thumb, r=alexcrichton

To build for the cortex-M series ARM processors LLC needs to be told to build for the thumb instruction set. There are two ways to do this, either with the triple "thumb\*-\*-\*" or with -march=thumb (which just overrides the triple anyway). I chose the first way.

The following will fail because the local cc doesn't know what to do with -mthumb.
````
rustc test.rs --lib --target thumb-linux-eab
error: linking with `cc` failed: exit code: 1
note: cc: error: unrecognized command line option ‘-mthumb’
````

Changing the linker works as expected.
````
rustc test.rs --lib --target thumb-linux-eabi --linker arm-none-eabi-gcc
````

Ideally I'd have the triple thumb-none-eabi, but adding a new OS looks like much more work (and I'm not familiar enough with what it does to know if it is needed).
[std::vec] Rename .get_opt() to .get()
[std::vec] Rename .head_opt() to .head(), drop the old .head() behavior
[std::vec] Rename .last_opt() to .last(), drop the old .last() behavior
[std::vec] Rename .pop_opt() to .pop(), drop the old .pop() behavior
[std::vec] Rename .shift_opt() to .shift(), drop the old .shift() behavior
[std::vec] Rename .remove_opt() to .remove(), drop the old .remove() behavior
[std::path] Rename .container_as_str_opt() to .container_as_str(), drop the old .container_as_str() behavior
[std::str] Rename from_utf8_opt() to from_utf8(), drop the old from_utf8() behavior
[std::str] Rename from_utf8_owned_opt() to from_utf8_owned(), drop the old from_utf8_owned() behavior
[std::str] Remove the now unused not_utf8 condition.
auto merge of #11129 : SimonSapin/rust/foo-vs-foo_opt, r=alexcrichton

[On 2013-12-06, I wrote to the rust-dev mailing list](https://mail.mozilla.org/pipermail/rust-dev/2013-December/007263.html):

> Subject: Let’s avoid having both foo() and foo_opt()
>
> We have some functions and methods such as [std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html) that may succeed and give a result, or fail when the input is invalid.
>
> 1. Sometimes we assume the input is valid and don’t want to deal with the error case. Task failure works nicely.
>
> 2. Sometimes we do want to do something different on invalid input, so returning an `Option<T>` works best.
>
> And so we end up with both `from_utf8` and `from_utf8`. This particular case is worse because we also have `from_utf8_owned` and `from_utf8_owned_opt`, to cover everything.
>
> Multiplying names like this is just not good design. I’d like to reduce this pattern.
>
> Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on the Option. I think we should rename every `foo_opt()` function or method to just `foo`, remove the old `foo()` behavior, and tell people (through documentation) to use `foo().unwrap()` if they want it back?
>
> The downsides are that unwrap is more verbose and gives less helpful error messages on task failure. But I think it’s worth it.


The email discussion has gone around long enough. Let’s discuss a concrete proposal. For the following functions or methods, I removed `foo` (that caused task failure) and renamed `foo_opt` (that returns `Option`) to just `foo`.

Vector methods:

* `get_opt` (rename only, `get` did not exist as it would have been just `[]`)
* `head_opt`
* `last_opt`
* `pop_opt`
* `shift_opt`
* `remove_opt`

`std::path::BytesContainer` method:

* `container_as_str_opt`

`std::str` functions:

* `from_utf8_opt`
* `from_utf8_owned_opt` (also remove the now unused `not_utf8` condition)

Is there something else that should recieve the same treatement?

I did not rename `recv_opt` on channels based on @brson’s [feedback](https://mail.mozilla.org/pipermail/rust-dev/2013-December/007270.html).

Feel free to pick only some of these commits.
auto merge of #11500 : jhasse/rust/patch-rlib, r=alexcrichton

Currently `rustpkg` only looks for shared libraries. After this patch it also looks for `*.rlib` files.
Add an AtomicU64 type to std::sync::atomics

This also generalizes all atomic intrinsics over T so we'll be able to add u8
atomics if we really feel the need to (do we really want to?)
Enable the +v7 feature on Android by default

With the recently added double word CAS functionality on 32-bit ARM (enabled via
a 64-bit atomic instruction in LLVM IR), without some extra features enabled
LLVM lowers code to function calls which emulate atomic instructions. With the
v7 feature enabled, proper 64-bit CAS instructions are used on 32-bit arm.

I've been told that v7 for arm is what we should have been doing anyway. This is
overridable by providing some other non-empty feature string.
extra: Make room for more sync primitives
extra: Add an intrusive MPSC to be used soon