JSStream class>>encodeString:on: optimizes speed for Pharo but not always for other platforms. Move to platform-specific package.

[jbrichau]

The implementation of JSStream class>>encodeString:on: is a hotspot method when generating large pieces of Javascript. As such, its optimization is important. Optimizations may differ between platforms, requiring a specialization per supported platform.

In VAST, because of the distinction between String with Character and UnicodeString with Grapheme, the optimization needs to be very different to obtain reasonable speeds.

Therefore, the implementation of this method should be moved to platform-specific packages.

[marschall]

Right now we have a lot of direct references to class side methods of JSStream making adding custom implementations hard. One way to solve this would be to make the methods instance side, change the argument passed to #javascriptOn: to a JSStream instance. JSStream class >> #new and JSStream class >> #on: would have to look up the implementation class through GRPlatform similar to #jsonEncoderOn:. JSStream would become the default implementation and have to be de-optimized.

[jbrichau]

I thought about introducing a WAJavascriptEncoder and change how Seaside encodes Javascript strings to how it's done using WAJsonEncoder and friends. There even is functionality to share with the JSON encoder itself.