Fix bolt guide crash when using rainbow formatter

[op-ct]

Short description

Fixes #229

Follows the example of the human outputter.

Checklist

I have:

• read the CONTRIBUTING.md document
• read and accepted the Developer Certificate of Origin document and added a Signed-off-by annotation to each of my commits
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[nmburgan]

I'm not quite sure I understand how this was failing before...

needs more investigation

[binford2k]

I'm not quite sure I understand how this was failing before...

I'm not sure I understand why the variety of method signatures in https://github.com/search?q=repo%3AOpenVoxProject%2Fopenbolt%20print_topics&type=code

[op-ct]

I'm not quite sure I understand how this was failing before...

In 759f54c, the argument passed into the outputters' print_topics methods changed from outputter.print_topics(topics) to outputter.print_topics(topics: topics). The human outputter was updated to accommodate this with a keyword arg, but the rainbow outputter wasn't―so it interprets the topics: topics keyword as a positional arg (Hash) instead of a keyword (Array). When it tries to join the supposed "Array", it fails (as seen in #229)

[op-ct]

I'm not sure I understand why the variety of method signatures in https://github.com/search?q=repo%3AOpenVoxProject%2Fopenbolt%20print_topics&type=code

@binford2k I'm not certain of the original reasoning behind the additional **kwargs (conjecture below); I ported it to match the human outputter's signature for print_topics.

FWIW, the same commit (759f54c) updated the json outputter to accept print_topics(**kwargs) resulting in it interpreting the keyword arg as a Hash and thus outptting a semantically comprehensible topics key:

{"topics":["debugging","inventory","links","logging","module","modulepath","project","targets","transports"]}

The human outputter added a positional **kwargs in the same commit, possibly in solidarity (because I don't see any other use for it).

[binford2k]

@op-ct that makes this method explanation quite incorrect then! This mismatch is what threw me off.

Think you could fix that comment and add a bit like "we don't need the keyword argument; it's interpreted a hash and thus this outputs semantically correct json."