scheduled_task : Refactor adapter class state management

The adapter classes TaskScheduler2V1Task and TaskScheduler2Task mix the concerns of managing state for a specific task with methods that manage collections of tasks.

The following methods should be moved to class level, as they are not appropriate as instance methods:

• enum / tasks should be moved to class level - enum alias can be removed in favor of a single method
• exists? should be moved to class level
• normalize_task_name should be moved to class level
• delete should be moved to class level
• activate should be moved to class level, and instead of returning a RegisteredTask COM object, should return the adapter instance
• new_work_item / new_task should be moved to class level - new_work_item alias can be removed, and instead of returning a TaskDefinition COM object, should return the adapter instance (this may require making the previous value available as an instance member)

Some additional consideration should be given to renaming the adapter classes to something more unique than other existing class / easier to grep

Additionally, the general concept of allowing an instance of TaskScheduler2V1Task / TaskScheduler2Task to switch it's identity from one managing one task definition to another, should be removed in favor of binding once at creation or activate time.

• new_task should be responsible for creation of a new task
• activate should be responsible for opening an existing task - consider renaming activate to something more indicative of its behavior

Any additional methods that are helpers for resetting state within an adapter instance (and any corresponding tests) should be removed, including things like:

• the clear_task method of taskscheduler_api2