Turn tasks into components

This MR explores what is required to make smtk::task::Task inherit smtk::resource::Component. The motivation is to allow operations to more easily modify a project's workflows and report results that way.

The changes here are incomplete, but enough to get tasks working with the modified inheritance. The remaining work includes (but is not limited to):

• Adaptor should also inherit smtk::resource::Component.
• The task manager does not currently have its parent resource/project set.
• The project does not implement methods to find tasks by UUID or search string.
• Deserialization is tested and works, but serialization is untested. In both cases, some remedial work should be done to clean up unused code now that UUIDs serve as persistent (not ephemeral) task IDs.
• Operations should be created to change the active task.
• It might be wise to refactor the observers currently triggered by smtk/task/Instances into an operation observer that notifies of changes in reported tasks.

@bob.obara @john.tourtellott FYI.

doc/release/notes/task-component.rst

+Task System
+-----------
+
+Tasks are now components
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The :smtk:`smtk::task::Task` class now inherits :smtk:`smtk::resource::Component`.
+Instances of tasks are still owned by the task manager, but it is now assumed that
+the task manager is owned by a :smtk:`Resource <smtk::resource::Resource>`.
+This has far-reaching consequences:
+
++ Tasks may have properties and links (such as associations to attributes).
++ Tasks must not be modified outside of operations (for thread-safety).
++ The parent resource must provide operations to find, insert, and remove tasks.
+  The Project class now provides these.