Better abstractions for current concrete tasks and measures: `ConcurrentTask`, `PhoneSensorMeasure`.

[Whathecode]

The current concrete classes for TaskDescriptor and Measure (ConcurrentMeasure and PhoneSensorMeasure) were introduced very early on. We have since learned a lot, and are in the process of adding new measures and tasks. This makes it a good time to re-evaluate whether we like the current concrete abstractions.

ConcurrentTask:

• The ideal that this simply tries to start all measures and outputs (not yet modeled) immediately and fails in case this is not possible is perhaps too broad of an abstraction to be useful now. In practice, we have only used this task so far to start passive sensors. The idea after a meeting is to rebrand this as a PassiveSensingTask which may solely contain measures which collect data passively.

PhoneSensorMeasure:

• This is currently linked to much to a smartphone. What is common and was intended to be modeled here (and can be acted upon in the client) is that this requests passive data to be collected. Therefore, we want to rework this into a PassiveMeasure.

ActiveTask (working title):

• Some of the other tasks we have (SurveyTask), want to add (WebTask), and envision to add (SlideshowTask) all contain presentation logic: what to present and when to present it. In addition, we can envision that they might be more opinionated about when measures should start or stop within the lifetime of the task (e.g., for particular slides), unlike PassiveSensingTask of which the measures are expected to run until the task has been stopped (using a trigger).

Changing our current concrete tasks and measures accordingly will make code on client runtimes more reusable. They can act upon these common abstractions in a uniform manner.

[Whathecode]

@ltj I finally wrote up the refactoring requirements here for the upcoming WebTask as part of our technical meeting. Could you please have a proofread and see whether I am missing anything we discussed?

[bardram]

The ActiveTask is what i called a AppTask in CAMS.

[Whathecode]

I will omit the ActiveTask, which we ended up deciding to call InteractiveTask from this issue. It might still be needed, but it is unknown which members are common to these tasks at this time, and thus whether an intermediate abstract type is necessary.