Ensure @tracked assertion can be made a deprecation.

[rwjblue]

During recent refactors that landed in glimmer-vm@0.57 (Glimmer VM version that landed in Ember 3.22) we moved the internal infrastructure to ensure everything was in a tracking frame. This greatly increased the number of locations that would now fall under the standard read + write assertions.

For example, in glimmer-vm@0.56 the following would run without error:

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';

export default class extends Component {
  @tracked counter = 0;

  constructor() {
    super(...arguments);

    this.counter++;
  }
}

Now, obviously this is a bit contrived, but the point is that since component construction was not previously within a tracking frame it would not error due to the read then write of a tracked property.

As of glimmer-vm@0.60+ we do run this within a tracking frame (because nearly everything is automatically within a tracking frame).

The infrastructure being updated here (forceHardError argument to assertTagNotConsumed) was intended to ensure that it was not possible to end up with a @tracked property that was set after consumption during a tracking frame, but to still allow for things using Ember's markObjectsAsDirty (via notifyPropertyChange) to trigger a deprecation. Unfortunately, now that we have increased the areas of the codebase that are within tracking frames we can no longer use forceHardError internally if we want our host environments to satisfy their SemVer requirements (shouldn't be adding new failures for things that worked "fine" in a minor release of Ember).

This change in and of itself doesn't really do anything (all of the same things would still error) however it does allow host environments to leverage deprecateMutationsInTrackingTransaction as appropriate to issue a warning instead of a failure for cases that previously worked.

Related to emberjs/ember.js#19192
PR in Ember to take advantage: emberjs/ember.js#19282