Add a default implementation for `stx-editor-hover`

[pvdstel]

The default implementation of stx-editor-hover is stx--editor-hover, which defaults to the fail strategy. This change provides a default implementation, displaying the node's type information instead. The implementation was adapted from Statix's implementation in NaBL2.

Screenshot:

To note

This strategy does not employ the pp-TYPE strategy that Statix uses for its own hover information, and I'm not sure what exactly it's doing. The screenshot above demonstrates what it looks like.

[hendrikvanantwerpen]

Good idea to make this easier. However, the type property has no special status, so hardcoding an arbitrary string there doesn't seem very useful. Perhaps a strategy stx-editor-hover(pp|prop) in the API, which takes a pretty-printing strategy and the property name as arguments is convenient enough to easily add a hover without hardcoding names.

[pvdstel]

I've implemented it by modifying stx--editor-hover in the services.str, and then adding some overloads (not sure if Stratego calls it that) in api.str. I've added three overloads:

1. stx-editor-hover(pp | prop): simply passes both arguments on to stx--editor-hover unchanged.
2. stx-editor-hover(|prop): passes prop onto stx--editor-hover, but uses a default strip-annos; write-to-string as the strategy pp. I would say that if you're creating a new Spoofax project, you don't have a pretty-printer already set up.
3. stx-editor-hover: this one's in here for backwards compatibility. In addition to the default pretty printing strategy, it defaults to type as the prop. This behavior changes compared to the fail strategy. I would consider this to be a reasonable default prop name.

---

You mentioned that type is not a property with a special status. Does that mean that I can create a rule such as the following in Statix:

@e.myVeryOwnProp := someValue

with this rule having the effect that there now exists a property myVeryOwnProp on e?