Cannot name a field override because of @override annotation

[SamJakob]

Describe the bug
Naming a field override causes the @override annotation to resolve to the local field instead of to @override from dart:core. This also, rather confusingly, displays errors on the first field to be defined, rather than on the field named override.

@immutable
@freezed
class TestClass with _$TestClass {
  const TestClass._();
  
  const factory TestClass({
    required final int? id,           // <-- errors will mention this line...
    required final bool? override,    // <-- but removing this causes the code to be generated successfully.
  }) = _TestClass;
  
  factory TestClass.fromJson(final Map<String, dynamic> json) =>
      _$TestClassFromJson(json);
}

See also: dart-lang/source_gen#688

To Reproduce

See the code snippet above.

Expected behavior
Well, ideally, this would "just work". However, because the field is shadowing the import from dart:core and - as @jakemac53 rightly pointed out in the linked issue above - part files cannot declare imports, there might need to be some kind of workaround, or it can just error out and say that a field cannot be named import.

Proposed solutions
I've tried none of the following solutions, but off the top of my head, these could be some ways to solve the issue?

1. Is it possible to have some "swizzled" version of override that wouldn't be used by an end user that "extends @override from dart:core and place it in the freezed_annotations package. (e.g., freezed_override_annotation) and use that annotation instead?
2. Probably the most reliable solution is just to tell the user they cannot generate a field with the name override and refuse to generate the code based on that - that's also the approach anyone trying to name a field as override has had to take anyway - this would just make it less confusing as to the cause of the issue.
3. Maybe as well as showing the user an error, the user could be prompted to also import dart:core with some alias that is then used if that additional import is detected? (I think this would also mean it could be a private alias - e.g., _core which would certainly alleviate any naming conflicts).

[rrousselGit]

I'd rather not support this for now.