fix `yarn compile-devtools` errors on travis

[brendankenny]

so far everyone seems to be able to compile correctly locally, and master tests successfully even on the same devtools commit (master vs failed build). Need to find the source of the issue (even if it's just clearing caches or whatever)

[paulirish]

There are two clones happening. 1) the devtools frontend. 2) the protocol.

it's expected (and typically necessary) for both repos to be up to date. that part is up to a cron job on my machine and i've just verified that it's all looking correct.

So there's two git hashes in here to check.

Successful build:

• HEAD is now at 8a6afdc [DevTools] Display usage & quota information
• HEAD is now at 579f232 Roll protocol to r477431

Failed build:

• HEAD is now at 9a6d4e2 DevTools: allow setting individual console filter levels.
• HEAD is now at 579f232 Roll protocol to r477431

notably the failing build results say "0 error(s), 2 warning(s), 94.1% typed"

so really this shouldnt exit with non-zero.

cc @wwwillchen on why this line exits with non-zero if there are no errors.

[wwwillchen]

Couple of thoughts:

1. If I'm reading the Travis log right, I believe on the failed build it's actually checking out revision ffd3dba based on line 538 of build log. That commit actually removes the Storage part of the Protocol API that Travis is yelling about (ChromeDevTools/devtools-protocol@ffd3dba). I think the checkout --quiet is what's tripping people up (including myself initially)
2. Warnings result in non-zero exit code. This regex searches for any warnings or errors in the compile stdout. I can see why this is confusing. DevTools enforces no warning violations since Closure is already so loose. At the very least, I can improve the logging in compile_frontend.py script to say something like: "An error or warning detected! Exiting with non-zero exit code."

[wardpeet]

@brendankenny is this still an issue?

[paulirish]

We don't need this check anymore.
@paulirish to remove the items from travis.yml