Enhance request/response abilities of net_response input plugin

## Feature Request

An input plugin that can send multiple strings to a tcp connection while also reading the response of each action.

### Proposal:

Create a new `net_response_v2` input plugin to eventually replace [net_response](https://github.com/influxdata/telegraf/blob/master/plugins/inputs/net_response). Instead of using single values, it will accept a list of `send` and `expect` strings, and additionally add an `expect_banner` option and a `send_on_failure` option.

The `expect_banner` (if set) will be checked after the initial connection is made.
The strings in the `expect` list will be checked immediately after any `send` string has been executed.
If one of those `expect` strings is not found when expected the `send_on_failure` string will be sent if specified, otherwise the connection will be closed.

#### Questions

This seems like a good tactic so that new functionality can be introduced in a minor version change without impacting any existing uses and without complicating a single plugin to handle both conigurations, but I am not sure whether this adheres to any prior standard for plugin enhancements?

I would assume the v2 version is initially included in addition to the existing `net_response` plugin in a minor version update, but would entirely replace it on the next major version change?

### Current behavior:

The `net_response` input plugin currently only allows for single `send` and `expect` to be set. If a response is received immediately after the connection is opened the `expect` string will be tested against that. If a `send` string is then executed there is no way to validate the output of that command.

### Desired behavior:

The ability to execute any number of commands against a tcp connection while also validating their response.

### Use cases:

#### SMTP
One example is to monitor the smtp protocol, where you want to verify the initial 220 code as well as the 250 and 221.

```
$ telnet mysmtptest.com 25

Trying mysmtptest.com...
Connected to mysmtptest.com.
Escape character is '^]'.
220 mysmtptest.com ESMTP Postfix

> ehlo me.com
250-mysmtptest.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

> quit
221 2.0.0 Bye
```

The plugin may be configured with the following parameters.

```
expect_banner = "220"
send = ["ehlo me.com", "quit"]
expect = ["250", "221"]
send_on_failure = "quit"
```

In this case if the `250` response is not seen after sending the `ehlo` command a `quit` will still be sent regardless in an attempt to cleanly close the connection. For this example it does not make much difference, but there may be cases where continuing to execute the `send` commands after a failure is seen is problematic.

#### FTP
Another is ensuring ftp connections closed out as expected, by verifying the initial 220 and the final 221.

```
$ telnet myftptest.com 21
Trying myftptest.com...
Connected to myftptest.com.
Escape character is '^]'.
220 Hello.

> quit
221 Goodbye.
```

The plugin may be configured with the following parameters.

```
expect_banner = "220"
send = ["quit"]
expect = ["221"]
```

#### Custom Services
and then of course there is any custom service that you may have running to accepts input and respond appropriately. These may or may not have an initial banner. In this example it connects with no banner, issues an `info` command, and expects to see a `connected_clients` string.

```
$ telnet mycustomerservice.com 3125
Trying mycustomerservice.com...
Connected to mycustomerservice.com.
Escape character is '^]'.

> info
connected_clients:18
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
```

The plugin may be configured with the following parameters.

```
send = ["info"]
expect = ["connected_clients"]
```

Start by reading plugins/inputs/net_response and its existing tests to understand the current single-send and single-expect behavior. Define the new input plugin around lists of send and expect strings, expect_banner, and send_on_failure, then verify the SMTP, FTP, and custom-service sequences described in the issue with tests.

Written by the indexing model from the issue text.