Replace Job Semantics

# `Services` and `Cluster` can be confusing.

Replacing it with the following semantics.

* `Job`: create a pod. No scheduling semantics.

* `ParallelJob`: create multiple concurrent `Jobs`. Scheduling semantics. From the workflow perspective, dependency can be built on the `ParallelJob` but not on the individual `Job`.

* `SequentialJob`: create a series of sequentially executed `Jobs`. No scheduling semantics. From the workflow perspective, dependency can be built on the `SequentialJob` but not on the individual `Job`.

# Scheduling can be confusing.

Replace it with `every`, and distinguish it from `until` and `assert`.
(Although all these semantics use the same scheduling logic in the background).

- Questions: should we allow for concurrent `state`, `metrics`, and `cron` policies to be specified? If so, which operator is applicable ? Is there any case about this need?

No files, tests, or entry points are named. Start by locating the current Services, Cluster, and scheduling semantics, then clarify the intended Job, ParallelJob, SequentialJob, every, until, and assert behavior; the work is done only when the replacement semantics and concurrent-policy questions are resolved and covered by tests.

Written by the indexing model from the issue text.