Typed task model

[Lotram]

This PR is a suggestion of data models refactoring.

Why ?

1. Using our own Task model decreases the dependency to taskw, and improves typing / readability, instead of using plain dicts. Having our own abstraction simplifies the changes needed to switch the dependency from taskw to taskchampion.
2. The Issue (and child classes) becomes less useful, it does not hold any specific logic, I suggest an implementation where it's merged into Service.
3. This gives us a clearer split between data coming from external services (Service, record) and data inserted in taskwarrior

What's inside this PR

1. The Task and Udas models
2. Use these models inside Service / Issue, so we use that instead of plain dicts (in db.py, collect.py etc)
3. Merge Issue inside Service, as there is no clear difference between the two
4. Move several methods (the ones where self is only used to access the config) out of Service

Commits 3 and 4 are optional, I think they're improvements, but not necessary.
I only modified Linear to demonstrate this.
The idea is not to review it in details for now, there are probably some bugs, but to discuss the overall shape of the changes.

What's next ?

If we proceed with this changes, I would then use Task even more in db.py, and try avoid using dicts.
We could also replace calls to taskw.task.FIELDS by our own Task object