Add Session class and Session options decoration by plugins

[chabou]

This PR implements this RFC

It adds 2 new plugin hook to our API decorateSessionClass and decorateSessionOptions.

It unlocks some awesome new plugin possiblities. I made a plugin as an example (and a proof of concept): https://github.com/chabou/hyper-session-log

[juancampa]

Just one question/change. Otherwise LGTM

[juancampa]

Suggested change

	this.pty && this.pty.write(data);
	if (!this.pty) {
	console.error('Attempted to write to a session with no pty');
	}
	this.pty.write(data);

Maybe this? Looks like otherwise we could silently lose data. Or is there a case where this would be valid?

[chabou]

I anticipated the case: A plugin overrides the constructor and prevents the pty creation (without override this write method). It seems legit to fail silently.

But thanks to your comment, I think this is currently pretty hard to prevent this pty creation because it occurs in constructor. Such a plugin can't call super() and would break other plugins that have previously decorated this Class.

I think we should isolate pty creation in a init(options) function that plugin would override to prevent this pty creation without breaking constructor chain.

[juancampa]

This is cool, more extensibility! 🎉

[juancampa]

Thanks for addressing my feedback @chabou! Also, thanks for being patience with my response delay, I'm in the process of moving to a new place and these days have been pretty hectic 😅

I think it's reasonable to expect that a plugin that overrides init to prevent pty creation should also override other methods that use the pty (such as write). It might be better to have the base class be consistent and allow any potential inconsistencies to be handled by plugins that introduce them.

This approach could cause problems if, for example, there's a plugin that overrides init to do something else but still wants the pty to be created. It won't see any errors when write is called because it "accidentally" removed the pty

[juancampa]

In short: if a plugin wants to remove the pty, it should be its responsibility to also override the other methods.

[chabou]

Look at destroy() method.
I don't want to force plugin to override it only to prevent an error with pty.destroy().

My point is that plugin should focus on what it adds and not what it removes. Having base class that have conditional behavior, anticipating that some part could be removed is a good thing.

But I totally understand your point that missing pty could be an unwanted error and silent protection could be harmful.

I will add some warning.