fix: cmd+triple-click select all command output when first line wraps

[dpatterbee]

I found this bug was easily reproduced with any command that wrapped to multiple rows on the first line of its output. The cause is that we stop searching for rows once we reach the first one where row.semantic_prompt = .command, which means that we reach the bottom line of wrapped output and stop there.

This PR makes it so that we continue iterating until we reach a row where semantic_prompt != .command and then return the previous one (or the last one if we run out of rows).

I also updated the test cases to include this.

I considered that this bug would also be avoided if we didn't propagate the command semantic prompt to additional rows on wrapped lines, but I don't know enough about the shell integration to make a call on that.

Closes #4693

[mitchellh]

Thank you! This is looking good, just a simple request.

[jparise]

I considered that this bug would also be avoided if we didn't propagate the command semantic prompt to additional rows on wrapped lines, but I don't know enough about the shell integration to make a call on that.

One thing that can get tricky is, in our current row-based approach, the last prompt marker is dominant, overwriting any other markers that were emitted for that row. I'm not sure if that complicates the command case, but it is relevant for multiline prompts and input regions.

I wrote some related notes in 63747d1:

Going forward, we should revisit our semantic prompt implementation. Our
row-based approach is too limiting; lines can have multiple markers, and
markers should be recorded with their full coordinates so they can form
ranges.

See: https://per.bothner.com/blog/2019/shell-integration-proposal/