Add ability to filter json_info results by type.

[SpicyLemon]

I'd like to be able to filter json_info results by type.

Examples:

• Have it return results on just the string entries.
• Have it return results on only number and boolean entries.
• Have it return results on only scalar entries (string, number, boolean, or null).
• Have it return results on only iterable entries (array, or object).

[SpicyLemon]

Here's what I'm thinking:

Add a --filter <types> option where <types> is a comma separated list of types to keep, e.g. 'strings,nulls'.

Valid types: strings, numbers, booleans, nulls, arrays, objects.
These "types" would also be valid and represent groups of types:

• scalars = strings, numbers, booleans
• iterables = arrays, objects
• all = strings, numbers, booleans, nulls, arrays, objects

Then add some flags that are aliases for that option for the various types:

• --strings = --filter 'strings'
• --numbers = --filter 'numbers'
• --booleans = --filter 'booleans'
• --nulls = --filter 'nulls'
• --arrays = --filter 'arrays'
• --objects = --filter 'objects'
• --scalars = --filter 'scalars' = --filter 'strings,numbers,booleans'
• --iterables = --filter 'iterables' = --filter 'arrays,objects'

The flag versions are additive but the --filter <types> version is definitive.

Examples:

• --strings --booleans is the same as --filter 'strings,booleans'
• --numbers --filter nulls is the same as --filter nulls
• --filter nulls --numbers is the same as --nulls --numbers is the same as --filter 'nulls,numbers'.
• --filter arrays --strings --filter nulls is the same as --filter nulls.

All of this should allow for both singular and plural versions of the types.

Notes:

• By not including nulls in scalars, it's easier to ask for "all non-null scalars" (--filter scalars) while still allowing for "all non-iterables" (--filter 'scalars,null'). If nulls is included in scalars then "all non-null scalars" is not as obvious (--filter 'strings,numbers,booleans').
• I left the --all alias flag out because the word "all" is too generic on its own. Seeing --all as an argument its own doesn't provide enough context about what's being requested. The others, e.g. --strings are more obvious. I've really only included all as a type up there so that, if the command has some filter stuff early on that someone wants to disable, they can just tac on --filter all to the end of the command. I guess maybe an --all-types flag would work though, but saving that decision for later.

[SpicyLemon]

This functionality would also be handy in the json_search function.