Refactored enso-data crate and text utilities.

[farmaazon]

Pull Request Description

This is implementation of task https://www.pivotaltracker.com/n/projects/2539304/stories/180312587. The old enso-data crate was renamed to enso-data-structures and designed to have only those: data structures.

That required moving the structures related to Text positions (the text module containing Index and Span). Because the EnsoGL text area component has structures duplicating functionalities, they were moved to a separate enso-text crate and replaced the old usages of Index and Span.

Important Notes

• This refactoring required some thinking, what offsets should be primarily used in our code. I tried to have a consistent outcome without much more rewriting (the rewriting can be a part of https://www.pivotaltracker.com/n/projects/2540121/epics/4864521).
• As a side effect, the old issues with non-ascii characters in nodes are fixed.

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the Scala, Java, and Rust style guides.
• All documentation and configuration conforms to the markdown and YAML style guides.
• All code has been tested where possible.

[MichaelMauderer]

Should we do some more testing based on a list like the Big List of Naughty Strings? That could make sure we didn't miss any corner cases.

[MichaelMauderer]

Might be useful to explain valid according to what rules.

[farmaazon]

Should we do some more testing based on a list like the Big List of Naughty Strings? That could make sure we didn't miss any corner cases.

Well, I'm sure that we won't work properly on those naughty strings, because this task resolves only one sort of problems (others are covered by https://www.pivotaltracker.com/n/projects/2539304/stories/180392693)

User editing code should be able to freely use letters from all languages. - Pivotal Tracker

[mwu-tow]

Not blocker, just for consideration: I'd rather see explicit unit::Bytes to avoid confusion with bytes::Bytes, also singular Byte might make more sense than Bytes

[farmaazon]

Not blocker, just for consideration: I'd rather see explicit unit::Bytes to avoid confusion with bytes::Bytes, also singular Byte might make more sense than Bytes

If it is not a hard blocker, I would skip it for a while. I tried to apply this, but some things does not look well: Column and Line are also units, but this code:

pub fn first_line_start_column(&self) -> unit::Column

looks strangely to me: Without context, I would not know what unit is.