Standardize on `auto-save`, remove `autosave`

tl;dr

We should start using only the hyphenated "auto-save" and its variants--auto_save, and AutoSave--and make any adjustments to existing code that seem practical and beneficial.

Overview

We're currently inconsistent in our spelling of autosave/auto-save throughout the codebase. Most of the time it's just a minor annoyance, but it can make text search harder and even result in inconsistent APIs and endpoints. It violates one of the best-named software rules of all time: The Principle of Least Surprise. 😛 Here's a quick breakdown of the situation:

Routes

Four of each:

Filenames

Non-test files:

$ for i in autosave auto-save auto_save AutoSave; do echo "$i: $(find . -name \*"$i"\* -not -path \*test\* | wc -l)"; done

autosave:   0
auto-save:  0
auto_save:  1
AutoSave:   7

Specifically...

$ for i in autosave auto-save auto_save AutoSave; do echo "$i:"; find . -name \*"$i"\* -not -path \*test\*; echo; done

autosave:

auto-save:

auto_save:
./experience_builder.auto_save.inc

AutoSave:
./src/AutoSaveData.php
./src/Controller/ApiAutoSaveController.php
./src/Controller/ApiConfigAutoSaveControllers.php
./src/AutoSave
./src/AutoSave/AutoSaveManager.php
./src/AutoSave/AutoSaveTempStore.php
./src/AutoSave/AutoSaveTempStoreFactory.php

Total code occurrences

Including code comments and variable names--which are kind of all over the place--in non-test files:

$ for i in autosave auto-save auto_save AutoSave; do echo "$i: $(find . -name '*'"$i"'*' -not -name Test.php | wc -l)"; done    

autosave:    1
auto-save:   0
auto_save:   1
AutoSave:   13

Other

• At least a few JsonResponse-es have autosave in a key.
• At least one JsonResponse has "auto-save" in a message string.
• The "Component" field for Drupal.org issues is "Auto-save".

Proposed resolution

My conclusion: The precedent strongly favors two words, either separated with a hypen or underscore or camel-cased. Unfortunately, there are four API-impacting instances--four routes and a few API data keys that include the one-word form. Unless-and-until we start versioning the API, we'll probably just have to live with those. Other than that, I recommend...

1. Standardize on the hyphenated "auto-save" and its variants--auto_save, and AutoSave.
2. Document the decision. - Where?
3. Decide if we need to make any changes to existing code/documentation. - Just change the term wherever it's found.
4. Determine if there are any UI strings that we want to change. - There don't seem to be.
5. Let the dev team know about it once it's been committed to avoid confusion.

User interface changes

None.