Nice.  A few notes.

Docs: The initial doc paragraph now has 'module browser' rather than 'class browser'.  The change is needed 2 other places.  Could be part of this PR or another one.
* Chapter title: "Python class browser support".  The only instance of 'class browser' in the chapter.
* Module index: "Supports information extraction for a Python class browser."

Possible API changes based on IDLE module browser experience:

1. IDLE filters out the import nodes.  It would be nicer to not have to delete them by passing something like 'imports=False' (with True being the default for back compatibility).

2. With nested classes and functions added, the returned object is almost a tree of nodes, except that what should be the top 'Module' node is instead what should be its children dict.  This un-uniformity gets in the way of recursively processing the tree.

3. If there were a function that returned a Module node with its path and name, the same could be removed from all children except for new ImpClass nodes representing imported classes when imports=True.  Since users know the module passed to pyclbr, this might be true even without Module nodes.

4. If a user immediately inserts nodes into a tree widget, then the user may only need a iterator of minimal nodes (name, parent, startline).  This is enough when using tkinter.ttk.Treeview.   I have thought of doing this for IDLE by either simplifying a copy of the pyclbr code or traversing the AST, as the PR here does.  This would let top-level items appear in the widget as they are scanned instead of waiting until scanning is complete.