Question: should we do this for assert/assertM as well?

@hmemcpy I think it makes sense for assert / assertM. That way there are no imports and no conflicts (for such commonly-used names).

Great, I'll add those as well.
To be honest, one thing I keep doing manually when creating a new spec is:

1. Create a new file, type object MySpec extends DefaultRunnableSpec{caret}
2. Wait for the IDE to suggest adding import zio.test.DefaultRunnableSpec
3. Manually correct it to import zio.test._
4. Manually add import zio.test.Assertion._

This PR would make step 3 redundant, however for assertions I would still need to import each individual one. Perhaps it's worth thinking of somehow proxying all of them?

Hmm, I was afraid of that. I'm met with a problem. Adding the delegate calls for assert/assertM now cause the following issue with the macro:

DefaultRunnableSpec.scala:65:89: macro implementation not found: assert
[error] (the most common reason for that is that you cannot use macro implementations in the same compilation run that defines them)
[error]   def assert[A](expr: => A)(assertion: Assertion[A]): TestResult = zio.test.assert(expr)(assertion)
[error]                                                                                         ^

Unless there's a way of solving this issue without having to rearrange the code, I have a proposal. Now that #4242 was merged, I suggest consolidating gathering the source location for the assert methods via the implicit SourceLocation. This way, I think, we can call the asserts without the macro even. Not sure what this means for auto-labeling. Maybe @dkarlinsky can elaborate?

Ok, let me know what you want to do there. I do think consolidation is useful. I am not sure if that alone will solve the problem after we simplify Assertion to use macros (but it's possible).

@hmemcpy You can't delegate to macro methods, but you may delegate to the implementation of the macro:

  final def assert[A](expr: => A)(assertion: Assertion[A]): TestResult = macro Macros.assert_impl

I suggest consolidating gathering the source location for the assert methods via the implicit SourceLocation. This way, I think, we can call the asserts without the macro even. Not sure what this means for auto-labeling. Maybe @dkarlinsky can elaborate?

In Scala 2 you can traverse the tree surrounding the macro call / implicit summon, so you can preserve auto-labeling even with an implicit macro. But I think that's impossible in Scala 3, a macro can only inspect the tree that's passed to it, so in Scala 3 the assert will have to remain a macro.

Thanks @neko-kai! I'm afraid that if I go down this road I'd have to split the DefaultRunnableSpec into two implementations (for Scala 2 and 3), and I'm not sure it's worth doing at the moment...

Perhaps then we can keep this PR as-is, only introducing suite and testM, and assertions can still come from zio.test._ normally...

@hmemcpy You can put assert into a separate trait e.g. Assertions and have differing implementations for assert for 2 and 3.

@hmemcpy If you can sign the CLA, it's good to merge!