Implement bean property generation

[Kordyjan]

Fixes #10322.
This PR adds bean property accessors generation to the PostTyper phase of the compilation.
This is a draft as it needs some automated tests, but I wanted to get some feedback earlier.

Open questions:

• should some flags from properties be attached to the generated accessors? I'm thinking mostly about Abstract and Override.
• about the problem of synthetic methods being available depending on the compilation being incremental or not - should it be tackled now? How can it be tested?

[smarter]

about the problem of synthetic methods being available depending on the compilation being incremental or not - should it be tackled now? How can it be tested?

Yes, we should decide what we support before getting this in I think. It can be tested using separate compilation tests: in tests/pos you can create a new subdirectory for a test, then inside that directory you can create files like Foo_1.scala, Bla_2.scala, etc, files with the same _N suffix will be compiled together, the number N determines the order in which things are compiled (so Bla_2.scala will be compiled after Foo_1.scala and it will see the result of the compilation of Foo_1 on its classpath). This also works for neg tests (in tests/neg) if we want to show that some member is not accessible under separate compilation.

[Kordyjan]

I decided to change the way how @BeanProperty annotation works on deferred properties. In scala 2 it would generate abstract methods. However, in scala 3 those defs couldn't be overridden from scala code, resulting not only in annotation being useless but also in inconsistent bytecode being generated. In this implementation, accessors are always fully defined. Of course, they will still work if the annotated property is overridden in some downstream class and there is a test case checking that.

Right now the compiler will correctly report an error if some generated accessor would clash with existing def. However, I wasn't able to test that behavior with the neg test. Even though the error was raised, the test framework still was marking this compilation as successful.

Lastly, I've added filtering of synthetic accessors as simply not adding them to the class scope during the unpickling. I have no idea if this is the right way of achieving that but it seems to work and it requires checking each def only once.

[smarter]

However, I wasn't able to test that behavior with the neg test. Even though the error was raised, the test framework still was marking this compilation as successful.

Can you push a commit demonstrating this? I can have a look at it.

[Kordyjan]

Can you push a commit demonstrating this? I can have a look at it.

I have pushed it. Now, as I look at this, my guess is that the test framework is differentiating between normal errors and exceptions during post-phase checks. Should I add explicit checks for name clashes?

[smarter]

Otherwise LGTM!