Add debug page to assist in writing command_mappers

[msheiny]

Proposed Functionality

As a device onboarding power user, whom is tasked with expanding device compatibility, I want the ability to debug and develop command_mappers quickly.

Use Case

The current workflow of developing custom command_mappers can be a black box experience when things are not working as expected:

• The logging output from the job that comes from jinja can lead to mysterious error messages. I tried to improve this a bit in Expand tests to cover ssh logic #315 with a single expansion of the log statements. Suspect we can do additional logging expansion here.
• It's not 100% clear what is being passed to the jmespath / jinja filters at all times based on the documentation and naming conventions. It seems that obj is an ip address in most of the examples but sometimes it's also an obj with unknown parameters.

I propose we add a new page to the nautobot app explicitly for debugging command_mappers with the following inputs:

1. A textarea that allows pasting of Raw output of the target device in question
2. A textarea where you can paste the YAML chunk that defines a command:

        command: "show version"
        parser: "textfsm"
        jpath: "[*].hostname"
        post_processor: "{{ obj[0] | upper }}"

3. A button to trigger the test which will output debug information of what goes into each parser and comes out of it. So for the example above I'd want to see:

• The input that was passed into jpath
• The input that was passed into post_processor
• The final output that would be passed into the device onboarding app from this command parser.
• Any explicit errors encountered during this process.

[gt732]

I agree, currently going through this now writing an integration with a new device. It's very difficult trying to troubleshoot what exactly is happening behind the scenes especially whats being passed to jmespath/jinja at different stages of the import.