Move namespaces from FSharpy.TaskSeq to FSharp.Control

[abelbraaksma]

We should either target Microsoft.FSharp.Control or FSharp.Control. I noticed that these namespaces, or at least the first one, is auto-opened in F# projects. According to @dsyme that shouldn't happen, so that behavior may not stick, but FusionTasks does exhibit that behavior, see for instance this source file on Async extensions, which get auto-opened as soon as you project has a reference to that lib.

I'll have to toy with the options a bit. Maybe the above behavior is only that way because Async is a type in F# Core already, but TaskSeq isn't.

Just opening this to keep track of options. Suggestions welcome.

[dsyme]

They add their own AutoOpen in FusionTasks

https://github.com/kekyo/FSharp.Control.FusionTasks/blob/e326fc32b3ad314ea62c34b50e609434bdd1fa4b/FSharp.Control.FusionTasks/CommonAssemblyInfo.fs#L21

They don't need to be in Microsoft.* though, would be better if they weren't

[dsyme]

That is, if an assembly adds its own AutoOpen, then that indeed applies to the contents of the assembly.

However we won't add such an AutoOpen here

[abelbraaksma]

No, we won't. I figured, if it is the default behavior of F#, let's go with it. Otherwise, I think it is better if people just "opt in".

I used the same approach as AsyncSeq, i.e., not Microsoft.*, just FSharp.Control.TaskSeq.

[dsyme]

Thinking about it further, there are two things that may motivate an auto-open

1. people are not "used" to opening FSharp.Control, and may think it's already done
2. This library will likely want to add some functions or extension methods to Task, Async etc. Eg to allow "for" over IAsyncEnumerable. These are really hard to discover.

I'm not totally advocating a nanesuace AutoOpen and they should very rarely be used, but having thought about it a little more it's worth leaving oprn as a question.