FR: Methods to loop, pause, & randomize animated textures

I've put a lot of thought into this request over the past year or so as there are a couple of different ways to go about implementing it. What I've landed on which makes the most amount of sense to me is a combination of .eff file format enhancements and a couple of new sexps.

1. Addition of randomization flag to .eff file format

This would be a flag which allows us to define a range of frames in an animation to be played in a random order. A potential use case would be a particle effect which has a consistent startup and cooldown animation sequence, but a series of frames which play in a random order in the middle. Below is an example of how this may be formatted. If no range is defined, the entire animation would play in a random order.

```
$Type: DDS
$Frames: 40
$Rand: 10-20
$FPS: 60
```

2. Addition of a loop flag to .eff file format

Here's where things get a little complicated.

The loop flag would allow a range of frames, much like the $Rand flag, to be played in a number of loops defined either by the file format OR for infinity. In the infinity case, the loop could be terminated and the animation concluded via sexp. If the infinity/sexp part of this sounds niche, I can assure you that I have a very specific case necessitating it. Example below once more. For an infinite number of loops in the defined range, I would omit $Loop Count entirely.

```
$Type: DDS
$Frames: 40
$Loop Count: 4
$Loop Range: 10-20
$FPS: 60
```

3. Addition of stop-anim, start-anim, and stop-loop sexps

The first two new operators here should be straightforward. Stop-anim would cause an animation to stop on whichever frame number is defined. Start-anim would do the same but backwards, causing the animation to start on whichever frame is defined.

Stop-loop is a little more specific, and would allow the current loop to continue to the end of its loop range (using the example above, play to frame 20), and then continue on to the end of the animation (in the example above, frame 40). Stop-loop should probably include a boolean to either continue the animation from Frame 0, or stop the animation once it hits the end frame (again, 40 for the example above.)

IDEALLY we would be able to choose the mission objects affected by these operators, but it's understandable if that's not possible, and there exist workarounds to handle that in case it isn't.

I sincerely hope I've done an adequate job of explaining this request, and I am more than happy to elaborate and answer any questions.