Generic speech dispatcher does not respect voice type

if you run
```
spd-say -L
```
the variants listed there are actually not usable with `--voice-type` parameter. I would assume they were meant to.

Further, if you set a supported voice type from the hardcoded list of 8, this has no effect on the speech dispatcher defined in generic.c; this is true even if you name voice variants after the hardcoded list of 8.

I propose, if a voice is listed with a name in the `spd-say -L` table, `say.c` should set the voice (`-y`) parameter automatically to the associated name.

So if I have
```
AddVoice "en-US" "male2" "awb"
```
and type in
```
spd-say -t male2 hi
```
I would expect this to behave identically to
```
spd-say -y awb -t male2 hi
```

I am offering to fix this in the code myself, Im just making an issue in case anyone has comments on this.

I am also planning on making this generic so even if its not in the hardcoded list of 8 and the user has configured it with reasonable values, it will still work.

For instance
```
AddVoice "en-US" "alien1" "kal16"
```

would work with command
```
spd-say -t alien1 hi
```

and behave identically to the command
```
spd-say -y kal16 hi
```
(`-t` is omitted because currently invalid `-t` parameters yield a printed error, and I would not do this if I find a suitable match)

Start by reproducing the mismatch with the documented spd-say -L, -t, and -y commands. Read say.c and generic.c to trace how configured voice names and voice types are handled. Done means configured names such as male2 and alien1 select their associated voices without requiring -y, while unsupported types retain the existing error behavior.

Written by the indexing model from the issue text.