Use CommandType in more places

[IanManske]

Description

Kind of a vague title, but this PR does two main things:

1. Rather than overriding functions like Command::is_parser_keyword, this PR instead changes commands to override Command::command_type. The CommandType returned by Command::command_type is then used to automatically determine whether Command::is_parser_keyword and the other is_{type} functions should return true. These changes allow us to remove the CommandType::Other case and should also guarantee than only one of the is_{type} functions on Command will return true.
2. Uses the new, reworked Command::command_type function in the scope commands and which commands.

User-Facing Changes

• Breaking change for scope commands: multiple columns (is_builtin, is_keyword, is_plugin, etc.) have been merged into the type column.
• Breaking change: the which command can now report plugin or keyword instead of built-in in the type column. It may also now report external instead of custom in the type column for known externs.

[fdncred]

I don't really want to lose the granularity that we have in scope commands now. I haven't looked close enough at this PR to determine if that is happening. Do we have all these categories still, just represented in the type column?

│ 5 │ is_builtin │
│ 6 │ is_sub │
│ 7 │ is_plugin │
│ 8 │ is_custom │
│ 9 │ is_keyword │
│ 10 │ is_extern │

I'd like to be able to keep this level of detail if we can. Here's part of why I'm thinking this. I've been brainstorming a new command that is really about learning nushell. Maybe a tutor subcommand that has a kind of periodic table of commands that shows you how/where you can use them. This idea isn't fully formed yet but I was thinking of somehow grouping commands as described but with a flavor of "these commands work on tables", "these commands work on records", "these ... ints", "these ... strings", "these ... binary", etc.

So, I see a logical breakdown like these is_* bools as helpful for somehow participating in a periodic table of commands.

[IanManske]

The is_sub column is still present, this PR doesn't touch that.

My understanding is that all the command types are, or should be, mutually exclusive. So, collapsing them all into a single column doesn't lose any granularity. E.g., instead of where is_plugin it's now where type == plugin.

[fdncred]

Just looking at the list and not the code, it seems that is_builtin, is_sub, is_keyword could be one command, maybe? i'm not sure what is_extern refers to. I'm not real familiar with how nushell assigns any of these really.

[IanManske]

The current list of command types are:

• Custom: a def declaration
• Alias: an alias declaration
• External: an extern declaration
• Plugin: a plugin command
• Keyword: a parser keyword like if, for, use, etc.
• Builtin: all the other internal commands not covered by the above (they are not special in any way 😢)

At least, that is to my understanding, and so there doesn't seem to be much overlap.

[devyn]

I think this cleanup makes sense to me. There isn't a reason for those is_ methods to return true simultaneously, and much of the code just does an ugly match on all of them to figure out which one is true

[sholderbach]

Screaming at the comment above that was already out of date trying to explain the type.

Tuples considered harmful

[IanManske]

Ok, let's give this a go.