[MetaSchedule][Refactor] Clarify Integration Logic

[junrushao]

Based on @masahi's PR #10578, we are able to further simplify the logic and remove redundancy.

Changes:

• Remove MetaScheduleContext, which is not useful any more after Masa's new relay backend;
• Consolidate logic around ApplyHistoryBest, and slightly improve the error message;
• Separate integration.py into 3 files: apply_history_best.py, extracted_task.py and relay_integration.py;

These changes make future Relax integration easier - the only thing needed is to add relax_integration.py without having to worry about potential conflicts.

[junrushao]

CC: @YuchenJin@masahi@zxybazh@yongwww@sunggg

[YuchenJin]

LGTM! :)

[sunggg]

Overall, LGTM.
One quick question - it seems like this PR replaces MetaScheduleContext to ApplyHistoryBestContext?
Does it mean other functionalities, like tuning, does not need any contextual information?

[junrushao]

@sunggg Thanks for asking!

There is no breaking change in terms of API usage, given ApplyHistoryBest is the only framework-facing integration point. It's still used in the same way like:

withApplyHistoryBest(database=...):
...

MetaScheduleContext is no longer in use after @masahi's refactoring in both Relay (#10578) and Relax (tlc-pack/relax#92), so it makes sense to just remove it

[junrushao]

Does it mean other functionalities, like tuning, does not need any contextual information?

@sunggg For now, MetaScheduleContext doesn't support providing arbitrary contextual information, so removing it doesn't bring in any regression. In the future, we will need to think very seriously about what the best API design is in terms of supplying arbitrary contextual information

[sunggg]

@junrushao1994 Thank you for the explanation. Makes sense to me.

[zxybazh]

LGTM, thanks for the refactor!