Adding codecov uploading to github and buildkite with monorepo flags

[MichaelGHSeg]

• I've included a changeset (psst. run yarn changeset. Read about changesets here).

[changeset-bot]

⚠️ No Changeset found

Latest commit: dc649b0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[MichaelGHSeg]

This causes some spurrious validation warnings. I didn't see a definitive answer about whether a new jest version would solve it. We can add --coverage to the test command lines instead

[silesky]

    ...([process.env.CI, process.env.COVERAGE].includes('true') && isRootConfig
      ? { collectCoverage: true }
      : {}),
    coverageDirectory: '<rootDir>/coverage',

I've tested this --

Observations on this config:

1. on Buildkite/CI, when yarn run -T core test is run -- the coverage directory is in the packages/core. I am not sure that codecov can handle a bunch of individual "coverage" folders like that, or it can only handle one big honking coverage folder. Sticking with this pattern would be ideal.

2. We also support running yarn test --coverage at the monorepo root (which is a currently not a command we run on CI) which runs the test suite on every package -- and creates an aggregated coverage folder. We only don't do this on CI because we like having the CI steps be more atomic (test core, test browser, etc) -- it also is more flexible in the future if want to power up turborepo with distributed build caching.

I'm still kinda on the fence about whether we or not we should use the CI env variable for coverage, or whether that's confusing and we use the new COVERAGE env variable. (or ditch the process.env.CI and just run with --coverage, or, all three). There's too many ways to do this ;-)