introduce `asyncraises` to core future utilities

[arnetheduck]

Similar to the introduction of raises into a codebase, asyncraises needs to be introduced gradually across all functionality before deriving benefit.

This is a first introduction along with utilities to manage raises lists and transform them at compile time.

Several scenarios ensue:

• for trivial cases, adding asyncraises is enough and the framework deduces the rest
• some functions "add" new asyncraises (similar to what raise does in "normal" code) - for example wait may raise all exceptions of the future passed to it and additionally a few of its own - this requires extending the raises list
• som functions "remove" raises (similar to what try/except does) such as nocancel with blocks cancellations and therefore reduce the raising set

Both of the above cases are currently handled by a macro, but depending on the situation lead to code organisation issues around return types and pragma limitations - in particular, to keep asyncraises backwards-compatibility, some code needs to exist in two versions which somewhat complicates the implementation.

• add asyncraises versions for several asyncfutures utilities
• when assigning exceptions to a Future via fail, check at compile time if possible and at runtime if not that the exception matches constraints

[cheatfate]

I thinik you missed or here and it become as complex as noCancel. Because in case of or it should create union of exceptions of Future1 and Future2. Personally i do not like this primitive because it has weird design, for some reason it returns only errors, but not values. From my point of view it should not return errors too, but i think there some code around which depends on this ugly implementation. Same problem has and implementation, but at least it was marked as deprecated and i think we should at least start removing this deprecated functions, so we can introduce more proper primitives on its place.

[arnetheduck]

I thinik you missed or here and it become as complex as

Well, I intentionally left it out for now because it's not used that much - because of the default CatchableError raises, it's not wrong, just sub-optimal. That said, it is indeed an odd implementation so I don't really want to touch it in this PR - maybe it should be deprecated and maybe not, but I don't think it's worth updating to asyncraises right now.

start removing

Removing is not a problem generally but if another version is added with the same name, it becomes difficult to maintain compatibility or at least compile-time discoverability of what needs to be updated.