Consider deprecating return_callback feature of register_type

[tlambert03]

In retrospect, I think the return_callback option to register_type was probably an overreach of scope for magicgui in the first place. While it definitely allows some cool behavior in napari, this sort of magical processing of the return value seems better suited to in-n-out, or perhaps implemented directly in napari for this specific use case of adding something to the viewer with a callback connection:

# napari instantiates the widget somewhere
wdg = some_factory()

# connect callback:
if satisfies_some_condition(wdg.return_annotation):
    wdg.called.connect(_mgui.add_layer_data_to_viewer)

# add it to the viewer
viewer.window.add_dock_widget(wdg)

that will definitely require a gradual deprecation, but as I think about the complexities of processing return annotation types (e.g. do we support subtypes? etc...) i think it's probably better to remove that feature rather than elaborate upon it

Originally posted by @tlambert03 in https://github.com/pyapp-kit/magicgui/issues/541#issuecomment-1458227189

[Czaki]

I have strong worries that many people outside napari may depend on this magic. Maybe some of us should try to search GitHub against the usage of return_callback. As it allows to split implementation of the function with handling its output in one line of user code.

[tlambert03]

I have strong worries that many people outside napari may depend on this magic

yep, if this happens at all, it absolutely won't happen "quickly". It would be a multi-version deprecation warning, with a clear alternative. From a quick search, I can only find napari and magic-class using the return_callback argument to register_type.

cc @hanjinliu