Implement update commands for commonly-used entities

[nblumhardt]

Also fixes #346.

Automating with a shell and seqcli is great, except when an existing entity needs to be edited. So far no commands support any kind of update or edit, because there's so much variation between entities and complexity in specifying properties.

This PR proposes an immediate blanket solution, using the JSON format to round-trip edits.

seqcli signal update [<args>]

Update an existing signal

Example:
  seqcli signal update --json '{...}'

Arguments:
      --json=VALUE           The updated signal in JSON format; this can be
                               produced using `seqcli signal list --json`
      --json-stdin           Read the updated signal as JSON from `STDIN`
  -s, --server=VALUE         The URL of the Seq server; by default the `
                               connection.serverUrl` config value will be used
  -a, --apikey=VALUE         The API key to use when connecting to the server;
                               by default the `connection.apiKey` config
                               value will be used
      --profile=VALUE        A connection profile to use; by default the `
                               connection.serverUrl` and `connection.apiKey`
                               config values will be used
      --verbose              Print verbose output to `STDERR`

This works well with modern shells, e.g. PowerShell (edited for clarity):

PS > $warnings = (seqcli signal list -i signal-m33302 --json | ConvertFrom-Json)

PS > $warnings.Title                                                                                                                
Warnings

PS > $warnings.Title = "Freak-outs"

PS > (echo $warnings | ConvertTo-Json) | seqcli signal update --json-stdin        

PS > seqcli signal list -i signal-m33302 --json                                 
{"Title": "Freak-outs", "Description": "Automatically created", "Filters": [{"Description": null, "DescriptionIsExcluded": false, "Filter": "@Level in ['w', 'wa', 'war', 'wrn', 'warn', 'warning'] ci", "FilterNonStrict": null}], "Columns": [], "IsProtected": false, "IsIndexSuppressed": true, "Grouping": "Explicit", "ExplicitGroupName": "@Level", "OwnerId": null, "Id": "signal-m33302"}

Future type-specific extensions to update might provide alternative ways of setting properties.

[nblumhardt]

Unfortunately, this bug breaks template import in the latest version

[nblumhardt]

These changes are to support running each test case against a new, unique server instance. Previously, a failure in one test could leave the server in an unsuitable state for later tests, making it difficult to see which test actually failed.

[liammclennan]

have you flipped the bool here?

[nblumhardt]

Thanks; yes, that one's the fix 👍

[nblumhardt]

Previously the condition "worked" because it failed to take different casings of "ExpressionIndexes" into account, and so happened to return the correct value for that case.