Long stage names results in duplicate resource names and manifests in odd cross-stage remove/deploy issues

[bigbyte-dom]

Say your sst:app name is mylongappname and with two sst:stage names like awesomestagedom and awesomestagedom2.

When deploying certain resources, like lambda functions, where the resource names have low limits (e.g. 64 chars), and long names, it'll truncate parts to do its best but produce the same resource names for both functions.

Real-life-ish-example for two appsync resolver functions:
my-awesomesta-AppSyncDataSourceSomethingResolverFunctionFunction
my-awesomesta-AppSyncDataSourceSomethingResolverFunctionFunction

Note the 'FunctionFunction' is a real thing too, I've seen this a few times.

Each deployment/removal will mess with the other's resources in strange ways, which we think might be related to:
#4118

Here's where the magic happens:
https://github.com/sst/ion/blob/95ab0f6bde62cbfb0ab8967abc44d502b272acee/platform/src/components/component.ts#L184
https://github.com/sst/ion/blob/95ab0f6bde62cbfb0ab8967abc44d502b272acee/platform/src/components/naming.ts#L37

We ran in to this same issue with our deploy pipeline which deploys a stage-per-pr. We had each PR deployment prefixed with staging-88' which then rolled into staging-89' as they were both trimmed to staging-8. Our PRs are no pr-88 as a workaround.

We tend to deploy app-per-AWS Account, so having the app name removed or truncated doesn't affect us, but it may bother some in a similar fashion.

Possible preference on failing the build with an error message, or deterministic hashing long resource names after the stage (and appropriate use of AWS resource tag explorer and full-name-tagged resources).