Two constants are defined in StringExtensions:
UmbracoValidAliasCharacters
UmbracoInvalidFirstCharacters

They were used exclusively by umbraco/js/UmbracoCasingRules.aspx.cs to define some JavaScript variables
which in turn were used by genericProperty.js to provide validation for aliases.

UmbracoCasingRules.aspx and genericProperty.js are used in:
  Umbraco.Web\umbraco.presentation\umbraco\controls\ContentTypeControlNew.ascx
  Umbraco.Web\umbraco.presentation\umbraco\controls\GenericProperties\GenericProperty.ascx

genericProperty.js defined the following functions:
  safeAlias(alias) : provides a safe alias version of alias
  isValidAlias(alias) : whether an alias is safe
  checkAlias(id) : plugs a safe alias validator / corrector on an element
  duplicatePropertyNameAsSafeAlias(propertyId, aliasId) : creates the alias from the prop. name

These are used to validate the alias of the content type, and of properties. No other alias in
Umbraco back-end seem to be validated in UI at that point. And, there seem to be no server-side
validation so the server just seems trust the UI.

Whereas in theory, we should only accept that the casing required by the user is different
from what our "toSafeAlias" method would provide, anything else is a validation error.

Legacy safe aliases accept leading and trailing dashes and underscores.

REFACTOR

Abstract string methods into IShortStringHelper, and create a new DefaultShortStringHelper which
re-implements methods in a clean nice way. The new aliases do not accepts dashes, nor leading
underscores.

Entirely refactor StringExtensions to rely on IShortStringHelper (via a resolver).

The constants in StringExtensions should go, but we keep them for backward compatility.
The legacy helper is 100% backward compatible even at JavaScript level, but the new helper
is NOT, it does server-side validation of aliases, all sorts of things, using an api service.

UmbracoCasingRules.aspx.cs is _gone_ in all cases, replaced by the JavaScript served by
the api service.