Make attache-control a long running sidecar

[beautifulentropy]

Previous to this change, we've avoided hashicorp/nomad#10058 by adding a long
sleep before attache-control would otherwise exit successfully. Unfortunately
this still means that subsequent scaling deployments will fail if the sleep
incurred from the initial deployment has expired.

This change makes attache-control a proper sidecar (long running ephemeral
post-start task). Instead of exiting after a successful run, attache-control
will stop the ticker channel and continue running until it receives a kill
signal.

• Configure attache-control as a side-car in the example nomad job
• Remove attempt-limit flag and cliOpts.attemptLimit
• Split the main func of attache-control into helpers
• Add helper methods to scalingOpts
• Replace calls to time.Tick with time.NewTicker
• Add renewChan (chan struct{}) and acquired (bool) to the lock struct
• lock.Acquire() sets lock.acquired to true, initializes lock.renewChan, and calls
  lock.periodicallyRenew() in a long-running go-routine
• lock.Cleanup() closes lock.renewChan and sets lock.acquired to false

Fixes #6
Part Of #11

[beautifulentropy]

@pgporada just a heads up on this. There will need to be some changes to the redis-cluster nomad job:

• Set sidecar = true in the lifecycle stanza of the attache-control task
• Remove flag attempt-limit from attache-control if you currently set one

[beautifulentropy]

Added a basic repro of the subsequent deployment failures to hashicorp/nomad#10058:
hashicorp/nomad#10058 (comment)