Reconsider module structure and struct naming.

Our crate module is getting quite convoluted, maybe we should stop reexporting everything and start adhering to the Rust style guide for struct names (avoid module name as prefix).

This came up in #1039 regarding this line in lib.rs:

pub use alert::{AlertButton, AlertIcon, AlertOptions, AlertResponse, AlertToken};

According to the Rust style guide we should be calling these just Button or Options and then use them like alert::Button or alert::Options.

This will of course mean that the naming will collide with widget::Button if you were to import everything into the same scope, but I don't think typing alert::Button is worse than AlertButton.

This would make even more sense if we would not reexport everything in the crate root, because then you would have to use alert::AlertButton which is pretty redundant.

And splitting up our crate module into multiple modules would make it less overwhelming when looking at it on docs.rs, especially as it is going to grow ever further over time.

I do understand the convenience part of having 'everything' in one module when writing import statements by hand, but by today Rusts tooling is getting better quickly and auto imports in Analyzer are working really well for structs and enums.

Because of this I would propose doing what we did with lens for all modules: avoid c-style prefixes for struct names and maintain a similar module structure to what we have in druid internally.

As @xStrom mentioned rightfully:

If we decide to organize them differently then that would also mean a ton of broken docs links though. So I think even if we want to change that and move things into modules, we should wait until better doc linking is stabilized which looks like it might happen this year.

So for now this issue mostly a reminder and place for discussion.

Start with the crate reexports in lib.rs and compare the alert, widget, and lens module structure. Review the naming and documentation-link implications described in the issue; this issue is done only when a concrete, agreed migration scope replaces the current discussion.