replace .taskcluster.yml file with Positron-specific version

[mykmelez]

This branch uses TaskCluster's support for GitHub to add continuous integration to Positron. Currently, it just builds the app, and TaskCluster reports the result via a comment on each change (or changeset) as well as an annotation on each pull request (I think; will know for sure once I create this pull request). In the future, we should be able to add tasks that run tests as well, once we have tests running.

This is essentially a wholesale replacement of the existing .taskcluster.yml file in the top-level of mozilla-central, so the whole file view is a better read than the default diff view. Unfortunately, we have to overload that file (and resolve spurious conflicts when merging from upstream) because it's the only file TaskCluster can inspect to determine whether and which tasks to run. But it also doesn't get updated very often (per its history), so I don't anticipate many merge conflicts.

The build environment is this [naive Docker image)(https://hub.docker.com/r/mykmelez/docker-build-positron/) from this Dockerfile that is based on Ubuntu 14.04 (Trusty), installs taskcluster-vcs to pull partly from TaskCluster caches, and uses mozilla-central's bootstrap.py to install build dependencies. (There are undoubtedly many ways to improve this environment, but it should suffice for the time being.)

Oh, and: I developed this in the taskcluster-yml branch in https://github.com/mozilla/positron instead of my https://github.com/mykmelez/positron personal fork because TaskCluster only runs for projects in the "mozilla" org. That's a downside of TaskCluster, relative to CI services like Travis and CircleCI, which you can configure to build your personal repo. But, on the plus side, TaskCluster supports all three primary desktop OSes, and it doesn't impose time limits that are too short for Positron and other Mozilla apps. I'm unsure what this means for CI of pull requests from personal forks.

[mykmelez]

@brendandahl, can you review?

[mykmelez]

The last job failed because the checkoutandbuild task was killed for taking too long:

101:10.77 libjs_static.a
101:16.78 libxul_s.a.desc
101:16.80 libxul.so
101:25.24 gdb-tests
101:42.57 In file included from /repo/obj-x86_64-pc-linux-gnu/js/src/jsapi-tests/Unified_cpp_js_src_jsapi-tests1.cpp:128:0:
101:42.57 /repo/js/src/jsapi-tests/testGCAllocator.cpp: In member function 'virtual bool cls_testGCAllocator::run(JS::HandleObject)':
101:42.57 Warning: -Wmaybe-uninitialized in /repo/js/src/jsapi-tests/testGCAllocator.cpp: 'growUp' may be used uninitialized in this function
101:42.57 /repo/js/src/jsapi-tests/testGCAllocator.cpp:56:5: warning: 'growUp' may be used uninitialized in this function [-Wmaybe-uninitialized]
101:42.57      if (growUp)
101:42.57      ^

[taskcluster:error] Task timeout after 7200 seconds. Force killing container.
[taskcluster 2016-07-25 20:31:40.725Z] === Task Finished ===
[taskcluster 2016-07-25 20:31:40.725Z] Unsuccessful task run with exit code: -1 completed in 7232.993 seconds

I'm looking into re-triggering the task.

[mykmelez]

Retriggered by rebasing with master, which created a new commit.

[mykmelez]

Last week these builds were taking about 50 minutes; the last one took 100. But that's still within the two-hour time limit. And that time limit is configurable with TaskCluster via the .taskcluster.yml file (unlike with Travis, which imposes a hard limit). So we can bump it up if builds start timing out on a more regular basis.