Some LTO fixes.

[ehuss]

This reworks the LTO computation a little to address a few issues:

• cargo build in a project with both a lib and bin would not engage the optimization introduced in Don't force rustc to do codegen for LTO builds #8192 where the lib should be compiled with -C linker-plugin-lto (bitcode only). This happened because the old code was starting root units as Lto::None. The solution here is to conditionally choose the starting Lto for roots.
• A project with a dylib dependency would fail to build. It was building the dylib with -C linker-plugin-lto which is not valid.
• A project with a bin/lib would build the lib differently based on whether or not it was selected. This changes it so that the lib is built the same. See lto::between_builds, where the second build the lib is now fresh.
• Tests/benchmarks of a lib target will now support LTO.
• Treats example libs a little more consistently as regular libs.

I scattered some comments throughout, hopefully it's not too difficult to follow.

Closes #8337

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[ehuss]

I'm not sure this is really necessary, it's a lot of code to do very little. The main thing is that I want to detect builds that don't pass any flags (Lto::ObjectAndBitcode), which is difficult to do with the current infrastructure. I could instead use with_stderr_line_without, or just not bother asserting that condition.

[alexcrichton]

Nah I think this is fine, it's just tests anyway so I don't think there's much need to be super strict about style and such.

[alexcrichton]

@bors: r+

All looks great to me, thanks for all the comments!

[bors]

📌 Commit 62a61dd has been approved by alexcrichton

[bors]

⌛ Testing commit 62a61dd with merge ee417cb...

[bors]

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing ee417cb to master...