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.

Comienza revisando Figure.java y las clases Plot de tech.tablesaw.plotly.api; después, lee los issues originales enlazados 716 y 693 para determinar qué cambios de API siguen siendo relevantes. El trabajo terminado debería conservar la API actual y permitir a la vez objetos Layout personalizados y clases Plot extensibles, pero el issue necesita definir el alcance y tomar decisiones de diseño antes de la implementación.