Use string_tree module in favor of deprecated string_builder module of Gleam

[diemogebhardt]

Since release 1.6.0 of Gleam, string_builder has been deprecated in favor of string_tree.

This PR:

• introduces BREAKING CHANGES:
  • Reasoning is that matcha is feature complete and stable. Whoever depends on string_builder just sticks with the current version and does not upgrade to the next/latest versions including this change. Reduces maintenance overhead for deprecated functionality – for example, in the case of a command line option.
    • Version 1.0.0 doesn't sound too bad, does it? ;)
    • In case you agree, this might need to be documented in README.md (including version/release numbers)
  • Updates gleam dependency (gleam_stdlib from version 0.38.0 to 0.43.0)
  • Uses StringTree instead of StringBuilder types in Refactor to use string_tree module instead of deprecated string_builder module of gleam
  • Renames public instances of render_builder to render_tree
    • In case the "builder" naming pattern should be kept, this commit just needs to be reverted.
  • Renames private instances of render to tree
    • In case the "builder" naming pattern should be kept, this commit just needs to be reverted.
  • Updates links to lustre and nakai in README.md
    • nakai just released a new version, adding support for the gleam string_tree module but dropping support for the gleam string_builder module completely.
    • lustre has an open PR (by me) to add support for the gleam string_tree module in addition to the gleam string_builder module.
• introduces minor gleam related improvements:
  • Formats gleam code
  • Reorders gleam imports
  • Ignores gleam build folder (git)

Going through the individual commits should make it easier for you to review all changes in digestible chunks.

All tests are passing. Generated gleam code by a "from source" build of this branch has been deployed by a few projects to production already. :)

[michaeljones]

Thank you very much for this. Looks great. I appreciate the clear commit separation for the different aspects of the change.

It looks like our CI hasn't been run for a while and needs updating so I'll push some commits to try to do that but otherwise it looks great and I'd be happy merge and I'm grateful for your efforts!

[michaeljones]

The further changes are presumably associated with newer versions of the rust toolchain and compiler warnings, etc.

[michaeljones]

You make a fair point about going 1.0. Let's see how this set of changes settles in and then we can go 1.0 (though I realise there is a risk I'll forget about it entirely!)

[diemogebhardt]

Thank you very much for this. Looks great. I appreciate the clear commit separation for the different aspects of the change.

Oh, awesome – didn't expect for this to get merged that quick. Happy to contribute whenever I can. And thank you, for creating this in the first place! :)

You make a fair point about going 1.0. Let's see how this set of changes settles in and then we can go 1.0

Yeah, going 1.0.0 feels like a big step. I see it from the perspective of communicating the breaking changes of a dependency, less than a set of features. SemVer is great for that. When upgrading matcha from version 0.*.* to 0.*.* I would just yolo it without thinking. Seeing the version increase from 0.*.* to 1.*.* I would definitely check out the changelog first in order to decide whether I want to spend the next couple of hours refactoring my codebase.

Even though off-topic in the context of this PR: is there a specific set of features that you would like to see for 1.0.0?

(though I realise there is a risk I'll forget about it entirely!)

Let me create an issue (#32) as a reminder and you decide whatever to do with it... ;)