The tool fails gracefully with error messages in this scenario, but it'd be a nice QOL update to smoothen first-time setup

The UUID-based filenames are great for ensuring no naming collisions occur, but they aren't readable. Giving them a more meaningful name will simplify developer workflows

git by default doesn't store empty directories, so the changelings/unreleased directory might get wiped with each publish. If the tool detects the directory doesn't exist, it should ask if it should be created. Related to #1.

Now that the interactive prompt, file manager, and disk writing utility are all mocked, we should follow best testing practices and use these mocks.

Acceptance Criteria:

• remove the dependency on TSCBasic from the PublishCommandTest cases
• replace all calls to withTemporaryChangelogEntry with hooks into the mocked disk writing utility

changelog amend: opens the most-recently-created changelog entry for editing, similar to how git commit --amend works

As the tool becomes more feature-rich, using command-line arguments for configuration options that won't change after initial setup (e.g. custom CHANGELOG filename) might be cumbersome. A config file where users can customize the tool may relieve this

It can sometimes be cumbersome to open the text editor and add entries using markdown syntax. Create an interactive way to add entries on the command line.

Example flow:

changelog add <-t | --ticket>
Enter the ticket number:
TICKET-1234
Enter the link to the ticket: 
https://blog.patrickgatewood.com

<create entry and emit existing success message>

Maybe let this be done via some flags too:
`changelog add <-t | --ticket>
^ don't forget about argument parser's ability to type check URLs!

After #2, this could be accomplished simply by typing
changelog add -t <hypertext> 1234❗️