Fix #578: doors state with setElementModel

[FileEX]

Fixes #578

Bug description
Changing vehicle model from doorless or "doorful" causes doors to fall off.

To reproduce

1. Take a tractor.
2. Set its model to a 4 door vehicle.
3. Doors fall off.

Now all vehicles without doors (tractor, baggage, etc.) will returns doors state as 0, because haven't doors. Now this vehicles returns doors state as 4 (missing).

[patrikjuvonen]

What is different in behavior when switching from a bike or tractor to a 4 door vehicle, and in reverse and repeated?

[FileEX]

Because the door 0 status also means the default lack of doors, and the state 4 means there is no door when we damage them and fall off. With setElementModel the vehicle status is saved from the previous vehicle. If the previous vehicle had door status as 0 (none) then the door is added. Now some vehicles, eg bikes, boats return the door status as 0, and vehicles from the (cpp switch) return the door status as 4 instead of 0.

[patrikjuvonen]

I was thinking maybe we could also look at implementing it so that if you switch from a doorless vehicle to for example a 4-door vehicle, it would add the missing doors automatically, as it's a bit weird that they are missing.

[FileEX]

My commit just fixes it, after switching from a vehicle without a door to, eg. 4 doors, the doors are automatically added.

[qaisjp]

How does this commit behave with other MTA versions? (It touches code that is touched in #70.)

[FileEX]

I do not know how this will affect this code, but this switch causes the bug that arises here, removing it does the trick.

[qaisjp]

How does this commit behave with other MTA versions? (It touches code that is touched in #70.)

Copying @Dutchman101's comment here from #13 (which was reverted and re-PRd in #70):

Seems to cause ProtocolError 60 through a desync, changes the return value of CClientVehicleManager::HasDoors() which is used in the net code (got this from ccw) if Bloodring banger is on map spawn, but cannot reproduce that simply with adding it to map and joining with r7454.
It may corrupt other data, the protocol error was reproducable 100% on r7454 and not prior revision in circumstances it first occured.

And this PR doesn't touch HasDoors, so it's probably fine.