API Changes requested

This covers a list of API changes suggested in the tablesaw repo. See original description below and original issue: https://github.com/jtablesaw/tablesaw/issues/716

I'm not sure what's left to do here that makes sense so a review is needed.

I would like to suggest some simple API changes to the jsplot-plotly classes which will slowly help in the direction proposed in issue https://github.com/jtablesaw/tablesaw/issues/693. If these suggestions sound acceptable, I can work on a PR.

Figure.java : Add methods .setTraces(Trace[]), .setLayout(Layout) & .setEventHandlers().

Figure.java : Change methods buildContext(), plotFunction(), eventHandlerFunction to "protected" instead of "private" so that they can be overridden.

For all Plot classes in tech.tablesaw.plotly.api.*, extend the classes to Figure.java.

Make the constructor of Heatmap (tech.tablesaw.plotly.api) public.

For all *Plot classes create constructors with parameters that match the static create() methods of each class, with an added Layout object. The constructors would do the same as the static methods except that it would setXXX() the layout, trace and eventhandlers instead of creating a new Figure.

If these changes are made, then the following will be true :

a) It will not break the current API.
b) It will allow users of Tablesaw to set a custom Layout object for each of the Plot classes.
c) It will allow users of Tablesaw to take advantage of inheritance and create classes which extend the Plot classes and override the underlying methods, so that they can make enhancements or changes to the current implementation.
d) It will allow users of Tablesaw to contribute their enhancements to the Tablesaw project, but still use their custom enhancements and the latest Tablesaw release while waiting for the acceptance of the enhancements and a new release with the changes.

Commencez par examiner Figure.java et les classes Plot de tech.tablesaw.plotly.api, puis lisez les issues d’origine liées 716 et 693 afin de déterminer quels changements d’API restent pertinents. Le travail terminé devrait préserver l’API actuelle tout en permettant des objets Layout personnalisés et des classes Plot extensibles, mais l’issue nécessite de définir le périmètre et de prendre des décisions de conception avant l’implémentation.