We are afraid that this will not easily be possible.
We would clearly recommend updating and modifying the art assets accordingly over having two runtimes next to each other. If you really want to get your hands dirty and try integrating both runtimes side by side, you can read on.

You need both runtimes with all files in the project cleanly separated, so that they don't reference the wrong classes. At least the following steps will be necessary to prevent compilation errors that I can currently think of:

For component classes:
You would at least need to change the name of every old component class that is recognized by Unity by name, e.g. from SkeletonAnimation to OldSkeletonAnimation, and also need to change the filename to match the component class name [1]. The .meta files should keep old references in scenes still intact. Note that changing namespace names alone will not be sufficient for component classes.

For non-component classes:
You still need to separate the non-component classes from each other, this could be done via added assembly definition files, which could be used to create four isolated projects:
spine-unity-old.asmdef for the old spine-unity non-editor directory
spine-unity-editor-old.asmdef for the editor part, with a dependency to spine-unity-old
plus for the new runtime, you can use the existing two asmdef files:
spine-unity.asmdef
spine-unity-editor.asmdef
This could be enough to prevent any reference going across the old vs. new border.

The above steps are necessary to make both runtimes compile while being next to each other, however you could be facing other problems down the line that we have not yet been thinking of, e.g. problems with different API or different behaviour at the respective Unity versions - the old Spine runtime will most likely not be compatible with Unity 2019, and the new runtime not with Unity 4.3 to list some extremes.

[1] You could theoretically have two classes with the same name and different GUIDs in the meta files, but this will be a hell to work with.