API update to support the newly added reexport field.

[mwu-tow]

Pull Request Description

IDE support for enso-org/enso#1793

Important Notes

This PR is based on Adam's API updated, as they are necessary for newer engine versions.
Will refrain from testing scenarios until "actual" merge is possible.
New field is not actually "used" (as in leading to visible user change), this PR only introduces API support.

Checklist

Please include the following checklist in your PR:

~- [ ] The CHANGELOG.md was updated with the changes introduced in this PR. ~

• The documentation has been updated if necessary.
• All code conforms to the Rust style guide.
• All code has automatic tests where possible.
  - [ ] All code has been profiled where possible.
• All code has been manually tested in the IDE.
  - [ ] All code has been manually tested in the "debug/interface" scene.
• All code has been manually tested by the PR owner against our test scenarios.
• All code has been manually tested by at least one reviewer against our test scenarios.

[farmaazon]

The only thing I don't like is the name. The export suggest that this an exporting line, and adding re- is confusing even more. Does if the module containing the object "re-export" this? Or maybe: does it mean, that the field will be filled only when the object is re-exported, and will be empty if only module containing it export it?

[4e6]

The logic behind the re-export naming is that every module implicitly exports all its definitions. Another module can re-export symbols that were defined in a different module.
In other words, module B takes the symbol exported from module A and re-exports this symbol with a new module name.

So, this re prefix only tells that this module is not the one where the symbol was defined.

[farmaazon]

So, this re prefix only tells that this module is not the one where the symbol was defined.

Ok, so in case when no module re-export given symbol, the reexport field will be empty and we ought to make import basing on the module field, right?

[MichaelMauderer]

@mwu-tow What is the status of this PR? Should it be updated/finished, or is it abandoned and should be closed?

[mwu-tow]

@MichaelMauderer
TBH I'm confused here. PR was ready to merge, apart from waiting review by Wojciech and next release bump.
However, it seems that #1726 actually duplicated parts of it, so now it is just mess.

Likely the missing pieces should be manually merged back.

[MichaelMauderer]

@MichaelMauderer
TBH I'm confused here. PR was ready to merge, apart from waiting review by Wojciech and next release bump.
However, it seems that #1726 actually duplicated parts of it, so now it is just mess.

Likely the missing pieces should be manually merged back.

This PR must have fallen through the cracks during the release process back then.

Can you bring this PR up to date or create a new PR with the things that still need to be merged? (After checking with planning about priorities)