[grouping info] Clarify messaging re: mismatched hashes

Sometimes we make changes to grouping without actually creating a new config, for example when we adjust the regexes we use for message parameterization. When this happens, affected events which came in before the change have hashes which don't match what the hash would be after the change. Since we don't store the entire `variants` blob which powers grouping, when we want to use it for the grouping info section we have to recalculate it, and so we sometimes end up with the aforementioned type of hash mismatch. In that case, we display [a message](https://github.com/getsentry/sentry/blob/93018044423ae1c3ae8061d322f4967b8bf7477f/static/app/components/events/groupingInfo/groupingVariant.tsx#L98-L103) in the grouping info section which looks like this:  The information is 100% accurate, but has real potential for causing confusion. It's important information, so we should definitely continue to show it, but ideally we'd do a better job of explaining what we mean and how it can happen. We should add a section to the grouping docs about it, and add a link to said section to the message. More complete list of ways this can happen: - The event was created/grouped with a grouping config which no longer exists (in which case we use the default grouping config to get grouping info) _and_ whatever changed between the two configs affects the event in question. - Since the event was created, we've changed our built-in stacktrace rules, fingerprinting rules, and/or grouping code without making a new grouping config, and whatever's changed affects the event in question. - Since the event was created, the user has changed their fingerprinting rules in a way which affects the event in question. One thing which won't cause this is the user changing their stacktrace rules in the meantime, since we store a snapshot of the rules at ingestion time (encoded in base64) as `event.grouping_config.enhance…