[📍] Make "test a patch" more discoverable

[dave-2]

For devs looking a performance regression, "test a patch" is often their primary action. We need to make it more obvious that we offer the functionality. We know that FABs have discoverability issues in general. In this case, it's even worse because we also have the "re-run this job" button in the same place. We should:

• Separate the two buttons.
• Move the buttons to the top-left.
• Add labels to the buttons, so people know what they're for.
• Eventually we may want to remove the re-run job button in favor of more interactive features where we can modify the existing job.

The updated material design guidelines have some ideas we can use, but unfortunately they are not available in Polymer yet.

@benshayden @simonhatch @perezju @anniesullie

[anniesullie]

Totally agreed! But I think we should also take a look at http://g.co/ChromePerformanceRegressions, which is the main entry point to the documentation when a developer is assigned a bug.

Specifically, under "How do I run the test?" it immediately links to perf tryjobs (good), which says "Visit Pinpoint and click the perf try button in the bottom right corner of the screen.", not clarifying that if you are working on a perf regression you really want to do this on the specific pinpoint page displaying your bisect results (needs improvement).

@dave-2 can you take a look at the documentation as well?