Ruby: Introduce depth_limit for Node#tree_inspect

[marcoroth]

This pull request introduces a depth_limit keyword argument for the Node#tree_inspect method. The reason for this is so we don't try to pretty print the whole AST in the terminal, especially on large documents.

At some point the output becomes hard to follow anyway and for big documents it takes quite some time to print the full AST, even if you are not even looking at the output. Limiting it, makes sure that you can fast feedback while not trying to print the full AST.

The output now looks like this if the depth limit is reached:

...  │   ├── @ HTMLElementNode (location: (9:16)-(17:22))
...  │   │   ├── open_tag:
...  │   │   │   └── @ HTMLOpenTagNode (location: (9:16)-(9:21))
...  │   │   │       └── [depth limit reached ...]
...  │   │   │
...  │   │   ├── tag_name: "div" (location: (9:17)-(9:20))
...  │   │   ├── body: (3 items)
...  │   │   │   ├── @ HTMLTextNode (location: (9:21)-(10:18))
...  │   │   │   │   └── [depth limit reached ...]
...  │   │   │   │
...  │   │   │   ├── @ HTMLElementNode (location: (10:18)-(16:24))
...  │   │   │   │   └── [depth limit reached ...]
...  │   │   │   │
...  │   │   │   └── @ HTMLTextNode (location: (16:24)-(17:16))
...  │   │   │       └── [depth limit reached ...]
...  │   │   │
...  │   │   ├── close_tag:
...  │   │   │   └── @ HTMLCloseTagNode (location: (17:16)-(17:22))
...  │   │   │       └── [depth limit reached ...]
...  │   │   │
...  │   │   ├── is_void: false
...  │   │   └── source: "HTML"
...  │   │
...  │   └── @ HTMLTextNode (location: (17:22)-(18:14))
...  │       └── content: "\n              "
...  │
...  ├── close_tag:
...  │   └── @ HTMLCloseTagNode (location: (18:14)-(18:20))
...  │       ├── tag_opening: "</" (location: (18:14)-(18:16))
...  │       ├── tag_name: "div" (location: (18:16)-(18:19))
...  │       ├── children: []
...  │       └── tag_closing: ">" (location: (18:19)-(18:20))
...  │
...  ├── is_void: false
...  └── source: "HTML"
...  

For deeply nested documents (like the one in #828) it went from ~10 s to ~300 ms.