pydrake: Make module organization more terse and consistent (e.g. use C++ namespace from modules)

[EricCousineau-TRI]

Update (2020-10-26)

Per Drake Developer meeting (doc), it is a bit painful to use full spellings for symbol imports the flavors listed here: https://github.com/RobotLocomotion/drake/blob/v0.24.0/doc/python_bindings.rst#whats-available-from-python

We should be able to make things more brief by using C++ namespaces to drive the pydrake module organization.

We pay the cost of non-granular dependencies (e.g. you need VTK, OSPRay, etc. just to import pydrake.math), but meh, whatevs, we haven't solved #6760 for a while, so we shouldn't hold back usability based on a 3-year-old issue.

This formulation may also resolve #12055, and possibly incorporate #7912

We should also consider a shortened import for pydrake, similar to how open3d, pandas, numpy, tensorflow, etc. suggest.

Slack conversations (a bit piecemeal, latest first):

• Name collision: https://drakedevelopers.slack.com/archives/C3YB3EV5W/p1603731739041400
• Consolidate modules: https://drakedevelopers.slack.com/archives/C3YB3EV5W/p1603534788035900
• Workflow for importing: https://drakedevelopers.slack.com/archives/C3YB3EV5W/p1601978247013800

---

Old (2019-07-17)

From this comment: https://github.com/robotlocomotion/drake/pull/11783#pullrequestreview-263001864

At present, we have things like:

pydrake.autodiffutils
pydrake.symbolic

Ideally, we should move them to reflect the module organization, either directly in pydrake.common, or underneath it as:

pydrake.common.autodiff
pydrake.common.symbolic

\cc @ggould-tri

[EricCousineau-TRI]

Updated to this address latest Drake Dev meeting notes.

FYI @jwnimmer-tri @ludwigschmidt-tri @RussTedrake