API naming changes

[MartinMalinda]

vue-concurrency API initially started to be as close as possible to ember-concurrency for a few reasons:

• it makes this library easy to understand for people who know ember-concurrency
• it helps preserving the same philosophy and keep the lib on the same path as ember-concurrency

however, there are also some challenges:

value

value is a problematic property name for a task instance because it might make it look like a value from Ref is being accessed and that's not the case. result could be a reasonable alternative

instance

• I'd argue that the term task instance is a bit confusing in ember-concurrency as well because it might imply that TaskInstance is some kind of instance of a Task class and that's not the case. In ember-concurrency Task + TaskInstance are both completely separate classes and instances are created from both of them (in the OOP sense). But in Ember this is still more tolerable because Ember is overall more OOP than Vue.
• vue-concurrency is under the hood not written in OOP, it's plain functions
• vue, especially vue 3 also turns rather towards functional programming (using hooks, avoiding classes, this). So coding beginners picking up Vue might have no OOP knowledge and the term Instance is not helpful to understand the concept.

It's harder to come up with a naming alternative here:

• TaskRun task.runs...
• TaskCall task.calls ...
• TaskPerform task.performs

Neither of these seem great.