Declarative modules next steps

declarative modules with the #[pymodule] mod X {} syntax is now merged behind the experimental-declarative-modules syntax (#3815).

The next steps are:

Before v0.21:

• document the new feature in the guide
• allow to export #[pyclass], #[pyfunction] and #[pymodule] that are inlined in the modules (in progress in #3902)

Before v0.22:

• properly register submodules in sys.modules automatically i.e. fix #759 by default
• allow #[pymodule_init] function to return () or PyResult<()>
• adding a class to a module via the PyAddToModule trait is currently relying on PyTypeInfo::type_object_bound. This function panics when module initialization fail. It would be better to throw an exception instead like in PyModuleMethods::add_class (in progress in #3919)
• investigate relationship between this and "two-phase initialization" e.g. #2245. In particular we should look at #[pymodule_data] as a way to create a per-module data mechanism (might be postpone to later)
• allow #[pymodule_export] const FOO = ...; to add constants to the modules
• investigate automatically filling the module parameter of #[pyclass] usages inside of decarative modules. #4213
• remove the experimental-declarative-modules feature flag to allow using declarative modules by default
• update examples, README and guide

Before v0.23 (or later?):

• Deprecate #[pyfn]
• Deprecate "function-based" modules

This is a broad roadmap rather than a single implementation task, and it names no files or tests. Start by selecting one unchecked item and reading its referenced issue, such as #759, #2245, or #4213. Done means completing that item’s implementation and updating this checklist when the associated work is resolved.