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

[ryneeverett]

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.
...

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

This makes sense to me in principle, but it doesn't seem like the decreased dependency on taskw has manifested in this PR. I'm kind of thinking a well-scoped PR might be focused on completely abstracting away taskw usage to prepare for #1078 . What do you think?

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.

I think there is a bit of a principled distinction between the two (described in the original doc-comments) but it might not be useful and probably isn't consistently enforced. I also think it's going to be hard to evaluate whether this change is an improvement if it is done at the same time as the Task model. Maybe we can hold off on this in order to reduce the scope of the Task model transition and so that we can better focus on getting it right if/when we do it?

[ryneeverett]

Thinking about this a bit more, I'd note that I think we are essentially on the same page. I see where removing UDA's from Issue makes that class even less useful and suggests elimination. I'd still suggest pushing that out to a separate PR though.

[Lotram]

This makes sense to me in principle, but it doesn't seem like the decreased dependency on taskw has manifested in this PR. I'm kind of thinking a well-scoped PR might be focused on completely abstracting away taskw usage to prepare for #1078 . What do you think?

Yes, as I see it, removing taskw dependency would be enabled by introducing our own Task model, thus in a follow-up PR. The main point of this current PR is my point 3: clearer split between external data and taskwarrior data.

But I definitely can remove the "Issue into Service" changes from this PR, and we'll do that later.
In my opinion, the main reason to do everything now is to avoid doing multiple breaking changes: I'd rather have 1 really big API change than multiple smaller ones. But as long as there is no released versions in between, it's not a problem, and we can have multiple PRs, I'm ok with that

[ryneeverett]

3. This gives us a clearer split between data coming from external services (Service, record) and data inserted in taskwarrior.

Could you elaborate on this a little bit? I noticed that some of the naming was more consistent which i appreciated, but I'm assuming you mean something more abstract/conceptual...