I'm afraid there's currently no way to persist an animation state in any of our runtimes out of the box. We have an open issue for it on the issue tracker on GitHub:
https://github.com/EsotericSoftware/spine-runtimes/issues/1185

This is an old issue, and we have since prioritized other things, also because the problem at hand is pretty complex to get working in 100% of cases.

The basic idea would be to serialize/deserialize all spTrackEntry instances the spAnimationState holds in its tracks. The serizalization of track entries is not too complex. For each track, fetch the current entry via spAnimationState_getCurrent(), then serialize that track entry and the chain of entries pointed to via its previous, next, mixingFrom, mixingTo, and timelineHoldMix fields. Track entries can also point to callback functions (listeners). You'll have to find a way specific to your project how to serialize/deserialize those.

Deserialization would then reestablish those track entries in an "empty" animation state. On the surface, this also not super complex, but we currently lack functions for animation state that let you create and setup your own track entries without going through spAnimationState_setAnimation/addAnimation. You can directly modify spAnimationState.tracks and spAnimationState.tracksCount for the time being.

I'd like to add that serializing the minute details of your animation system is not usually necessary. If you need to serialize your game state, you probably want to use a MVC or similar design, where the game model is separate from the animation system. You definitely want to avoid storing your game model in your animation system. See Super Spineboy for an example:
https://github.com/EsotericSoftware/spine-superspineboy/tree/master/src/com/esotericsoftware/spine/superspineboy

You can see how it works here:
https://github.com/EsotericSoftware/spine-superspineboy/blob/master/src/com/esotericsoftware/spine/superspineboy/CharacterView.java
The game state keeps track of what the player is doing, then this code checks if the corresponding animation is playing. If not, it plays it.

Then you just serialize your game model and deserialization will give you a game state that is good enough. It may not be exactly the same skeleton poses because when mixing from other animations to the current animation, the other animations will be lost, but it is sufficient in most cases. When it is not, the game state should store the information to restore the required animation state. Note that is probably still less than storing every detail about the animation system state.

Even AAA games do not serialize every animation. For example, see Dark Souls. Restoring a save state doesn't put you back into the middle of an attack. Doing so is unnecessary.

If you find it difficult to design your game that way, there are workarounds, such as disallowing saving during transitions or other problematic times.