Allow for dynamic display names based on dir names

[rbcasperson]

This is an interesting idea that I think will be useful!

display_name.txt is a great feature. Lets you make the docs titles look nice. But what if there is a pattern you want to follow based on the directory name? You can currently manually create a display_name.txt file in every directory, but then you have to remember to do that every time new directories are added.

This PR proposes a solution where you pass in a module/function pair that will translate directory names into display names. It works the same way that the --url-from-tag flag works, and it expects the value to be in the same format.

NOTE: There's weren't any unit tests for the --url-from-tag flag (see the code coverage). That isn't necessarily an excuse to not add them here, but perhaps it can be a FF to add tests for both. Either way I wanted to get this idea out there for early feedback, and I'll look into adding the tests nonetheless.

For context, we have our features dir structure match the API we are testing, and we want the docs to look like the actual url. So I have it pointing a helper that changes dir names to f"/{dir_name}", and puts curly braces around URL params. This makes it easier to see how the features in the structure matches the URL (the tests are really low level, so it makes sense to care about exactly which URL).

[rbcasperson]

Thanks @dgou, yeah I can certainly add an example on how to use it.

[rbcasperson]

When I was going to add documentation about the new flag, I realized that to keep it in line with the -url-from-tag flag, it should also support the parsers option. That allowed me to consolidate the documentation for both, but I had to add support for the parsers option, which also required some refactoring.

[bradsbrown]

NB thoughts after looking over this code:

• It's a little painful that we have to pass separate args to handle a config plugin vs a cli parser. I'm wondering if we can find a way to pull both together at some point (prioritize the CLI over config), then do one import.
• It's been a while since I've written the url tag parsing side, but at a glance I can't recall how the cli value is actually being put to work here for that one either.

[dgou]

After today's adventure, I think I want to pull this PR tomorrow and run it against my SNBN repo and make sure it's good, and re-re-review with fresh eyes in the AM.

[rbcasperson]

Thanks for the thoughts @bradsbrown. I agree that there is probably a nicer way to handle this. And it can probably apply to the url from tag logic as well. I already have one FF for this PR, so let me consider that as well.