to facilitate features like #246 (and maybe autocd opt) some sort of "command processing" pipeline can be implemented. these are distinct from runners since they arent meant to actually run commands, theyre just meant to turn 1 command input into another. it will need context on the current runner in use though.

a processor function signature will look like:

function processor(command)
	return {
		continue = true,
		command = ''
	}
end

• continue determines whether hilbish should continue with command execution (to pass it to a runner) or not. commands not continued will not be saved to history. this is the only required return value in the table.
• command if present will be the command string passed to the runner. if it is not present, it will use the same command string passed to the processor.

when defining processors, it will work with a number based priority system. the lower the number, the earlier it runs.
2 processors, one with a priority value of -10 and another with a priority value of 3, the processor with -10 priority will run first, and then be passed to the next processor. this means early priority processors determine if further processing and execution happens. default processors will have documented and stable default priority values.