Consider splitting into UI and non-UI pieces

[corranwebster]

Some of the parts of Apptools provide fundamental application services for any type of application (eg. preferences, persistence, naming, logging), but others are tightly tied to GUI features (preference UI, logging UI, undo/redo, scripting).

There may be a point to providing two packages: a low-level set of tools which depends only on Traits (and maybe, optionally, Envisage), and a high-level set of tools and interfaces to the low-level tools for use in GUI applications.

For backwards compatibility, the high-level toolkit should retain the Apptools name and at least for a while should import the low-level tools into the namespace.

[rahulporuri]

While splitting apptools into ui-specific and non-ui pieces is of interest, we have decided to not pursue this in Q4 2020. Removing this ticket from the Enthought OSS Q4 2020 GitHub project.