[prototype] AssetExecutionContext partition methods directly on the context

[jamiedemaria]

Summary & Motivation

This PR is a prototype for a potential API for partition methods on the AssetExecutionContext. It reduces the number of partition-related methods on the context by eliminating output methods (since the partition for an output will be the same for all outputs produced by the asset). The names of the methods are also updated to be asset-centric rather than input/output-centric and they will accept asset keys rather than input/output names.

Hooli PR - dagster-io/hooli-data-eng-pipelines#59
DOP PR - https://github.com/dagster-io/internal/pull/7903

How I Tested These Changes

[jamiedemaria]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

• master
  • PR Only have one kind of context for direct invocation #17554
    • PR duplicate op context methods on asset context  #18573
      • PR deprecate methods on AssetExecutionContext that can be found via the DagsterRun object #17339
        • PR Direct invocation asset execution context #18549
          • PR deprecate asset_partition_*_for_output on AssetExecutionContext #19436
            • PR [docs] remove asset_partition_*_for_output from docs #19437
              • PR deprecate op related methods from AssetExecutionContext #19441
          • PR Make upstream asset materialization events available on the context #18971
            • PR [wip] store the tags fetched by data versioning so we can use them for upath io manager #19324
              • PR [UPath I/O managers] special case handling of None outputs #18820
            • PR Make input partitions methods based on asset key not input name #19027
              • PR Support partitioned assets for fetching latest AssetMaterializations #19286
              • PR [do not merge] base example to showcase new apis #19199
                • PR [prototype] sub-context for each upstream dependency  #19283
                • PR [prototype] AssetExecutionContext partition methods on sub context #19236
                • PR [prototype] AssetExecutionContext partition methods given as named tuple #19037
                • PR [prototype] AssetExecutionContext partition methods directly on the context #19032 👈
            • PR [wip] two execution contexts with minimal changes #18543
              • PR [wip] see wht needs to change when asset context is no longer an op context #18553
        • PR support Asset and Op ExecutionContexts in standard execution path #17972
          • PR [wip] add AssetExecutionContext to direct invocation #18044

This stack of pull requests is managed by Graphite.

[jamiedemaria]

make all of these accept a CoercibleToAssetDep maybe? that way we can pass definitions around vs string matching on asset key? or maybe doing this is sufficiently good pattern

@asset(...)
def upstream():
   ...

@asset(deps=[upstream], ...)
def downstream(context):
      context.upstream_partition_keys(upstream.key)

allowing CoercibleToAssetDep could cause confusing scoping issues like this

@asset(...)
def upstream():
   ...

@asset(...)
def downstream(context, upstream):
      context.upstream_partition_keys(upstream.key) # upstream doesn't have a key in this case since it's a loaded value

[jamiedemaria]

from my understanding, this method is mostly used to check if a run is partitioned or not. In that case, I think a name like is_partitioned, is_partitioned_materialization/execution/run is better

[jamiedemaria]

This file will not get merged. It's an example of what some of these apis will look like in use