With this fix, doing
```
const stores= [writable(0), writable(1)]
derived(stores, ([a,b,c]) => {});
```
works without type errors. The propblem with the previous type signature was that it's too strict for TypeScript's suboptimal inference of the value `stores` in that example, which is `Array<Readable<any>>`, which does not convey the info "at least one element", which the old Stores signature required.
Runtime-wise, it's no problem passing an empty array to derived.
The new signature is only appended to, not replaced, because the old signature is able to correctly infer the values of each array entry: For `derived([writable(0), writable('foo')], ([a, b]) => {});` the parameters `a` and `b` are correctly inferred as `number` and `string`. If the type would be changed to `type Stores = Readable<any> | Array<Readable<any>>` that would be no longer the case.
Fixes #6178
A recent refactoring commit where the constructor definition was moved to an interface disconnected the props relationship of the props that are passed in the constructor and the instance props
Fixes #6291
Fixes #6345
Both writable and readable initialized without any arguments are already valid, but TS complains about it. This makes both allowed to be emptily initialized. It's also possible to invoke readable with one argument only.