Add assert_threads_result helper and threads test

[st0012]

Some notes:

• Ids don't always start from 0 and increment by 1, as shown in the below example. So asserting ids is pointless imo.
• Threads request is only supported in DAP server.
• Example failure message:

result:
{
"type": "response",
"command": "threads",
"request_seq": 8,
"success": true,
"message": "Success",
"body": {
"threads": [
{
"id": 1,
"name": "#1 /var/folders/yg/hnbymwxd5pn7v94_clc59y6r0000gn/T/debug-20220411-21868-x0t9a2.rb:6:in `<main>'"
},
{
"id": 4,
"name": "#4 /var/folders/yg/hnbymwxd5pn7v94_clc59y6r0000gn/T/debug-20220411-21868-x0t9a2.rb:2:in `block in foo'"
}
]
},
"seq": 9
}.
Expect all thread names to be matched. Unmatched threads:
<[]> expected but was
<["#1 /var/folders/yg/hnbymwxd5pn7v94_clc59y6r0000gn/T/debug-20220411-21868-x0t9a2.rb:6:in `<main>'"]>
diff:
? ["#1 /var/folders/yg/hnbymwxd5pn7v94_clc59y6r0000gn/T/debug-20220411-21868-x0t9a2.rb:6:in `<main>'"]

[ono-max]

Could you update CONTRIBUTING.md?

[st0012]

Sure. But speaking of documentation, do you think we can do that in Ruby comments? Like test-unit does. And in the contribution guideline we just link to the file.

I think it fits the convention better and it's easier for writers of methods (like me) to remember too 😛

[ono-max]

We can write how to use API in the comments and CONTRIBUTING.md. I think that writing the explanation in CONTRIBUTING.md is good because they are well organized.

[st0012]

I don't think having documentation in 2 places is a good idea. It's the same reason we only write command intro in session.rb and generate it in README.md, instead of having it in both places.

[ono-max]

Well, I see. Or, we can create rdoc page from the comment?

[st0012]

Yes. In that case, we'll need to write the comments follow yard's specification.

[st0012]

@ono-max I've updated the contribution guideline for now. can you check it? thx

[ono-max]

Nice work! LGTM

[ono-max]

You missed https://github.com/ruby/debug/pull/607/files#r843338555. Could you update it?

[ono-max]

We can use assert_match method in this case, could you tell me the reason why you implemented so?

[st0012]

Why do you think we can use it here? Remember, the order of threads info is not guaranteed. So we don't know which one will match.

[ono-max]

Ah, that's right. My bad 🙏

[st0012]

No worries 😉
Do other changes look good to you?

[ono-max]

Can we use assert_empty?

[st0012]

I decided to use assert_equal because it provides better highlighting in the failure messages:

assert_empty

I guess it's because assert_empty doesn't care about individual items in the array, but assert_equal does. So it provides a more detailed information.