Make asset checks matter to integration tests

[jdangerx]

Overview

Closes #3705 .

What did you change?

• we weren't running asset checks in our ETL when running in integration tests. Instead of making a new, different ETL job for integration tests, we now just run the same job we use everywhere else, but with whatever dataset configuration we have defined for the tests.
• we also weren't asserting that the ETL execution actually succeeded. Asset check failures currently cause Exceptions, so we don't technically need this, but it seems prudent to assert success anyways.

Testing

• verified that the fgd_equipment_null_check asset check passes, by running the raw_eia860 assets and then the _core_eia860__fgd_equipment asset in Dagster
• ran integration tests with make pytest-coverage and saw the integration tests pass
• break the fgd_equipment_null_check by making it return AssetCheckResult(passed=False)
• re-run the _core_eia860__fgd_equipment asset in Dagster and see the check fail
• re-run integration tests with make pytest-coverage and see that the integration test fails with a bunch of errors about dagster._core.errors.DagsterAssetCheckFailedError: Blocking check 'fgd_equipment_null_c heck' for asset '_core_eia860__fgd_e...

To-do list

Preview Give feedback

1. Ensure docs build, unit & integration tests, and test coverage pass locally with make pytest-coverage (otherwise the merge queue may reject your PR)
2. Review the PR yourself and call out any questions or issues you have

[jdangerx]

Frustratingly, running make pytest-coverage on this branch has caused a bevy of apparently unrelated errors in the integration tests so I will need to poke around more to validate that this indeed causes our tests to fail on failed asset checks.

[jdangerx]

This was only being used in conftest so I moved it over to avoid some import issues.

[jdangerx]

I removed one layer of function nesting here because it seemed unnecessary based on the reconstructable jobs docs.

Since we're only using execute_in_process right now anyways, we don't even need a reconstructable job, but it seems fine to leave this because the logic is pretty straightforward now.

[jdangerx]

Instead of making whole new JobDefinitions I just return the ones we actually use in other builds - that should make test behavior hew more closely to production behavior.