Add shorthand way to express service dependency prestart task

In order to setup a prestart dependency check for another service when starting a job the current way of doing this is the below according to the [training docs](https://learn.hashicorp.com/nomad/task-deps/interjob#create-the-mock-app-job-file):
```
task "await-mock-service" {
driver = "docker"

config {
image = "busybox:1.28"
command = "sh"
args = ["-c", "echo -n 'Waiting for service'; until nslookup mock-service.service.consul 2>&1 >/dev/null; do echo '.'; sleep 2; done"]
network_mode = "host"
}

resources {
cpu = 200
memory = 128
}

lifecycle {
hook = "prestart"
sidecar = false
}
}
```

It would be really good to be able to shrink this very simple but hugely verbose (20 lines!) into a shorthand notation to be used in Nomad. The current way is great for its flexibility to execute any commands as startup dependencies, but looking up another service as a dependency before starting another task is such a common case that the above boilerplate tasks become quite cumbersome.

Instead it would probably suffice to do something along the lines of the below:
```
group {
prestart "mock-service-dependency" {
service = "mock-service.service.consul"
interval = "5s"
}

task { ... }
}
```
Not sure if its a feasible idea to make a prestart/dependency stanza per se, but just being able to skip setting up the docker config, resources and all of the stuff from the training docs and just state what service we want to depend on, and how often we want to poll would be nice and simple for this common use case. This could perhaps only be enabled if Nomad is clustered using Consul, since that should allow Nomad to access the Consul api to find out whether or not the dependency is alive and in the DNS or not.

Start with the linked training docs and the existing prestart task-dependency example. No source files or tests are named, so first locate the lifecycle and service-check configuration entry points and determine how Consul-backed checks would fit. Done means the shorthand syntax, polling behavior, and validation are agreed and covered by appropriate tests.

Written by the indexing model from the issue text.