AI: Per waypoint speed

[tritonas00]

• Custom per waypoint speed can be now defined in UI or the json file. Values >= 5 km/h are respected, -1 system default, can be skipped in json.
• Recorder records the speed
• Exporter exports the speed

Code changes:

• Moved vector ai_waypoints to GUI_TopMenubar so now all ai_* vars are in one place and made it a struct
• std::map<int, float> waypoint_speed changed type from int to Ogre::String (way0, way1 ...) so custom speeds are correctly aligned in all repeat times

[ohlidalp]

I skimmed the code and I like it, but I have things on my mind:

• The AI panel now makes good 1/4 of total code in TopMenubar.cpp and it's obviously going to grow, so if you're already migrating data around, it would be good if you made a separate GUI::VehicleAIPanel class for it. I don't mean to change the way it's drawn on screen, just the internals. You don't have to do it now, but eventually it'll become necessary.
• I'm pondering how to integrate vehicleAI with the mission system (AI opponents in race, AI traffic, AI forklifts in warehouses...) - The modder will want to pre-configure multiple AI vehicles in the mission file. Waypoints can be loaded from JSON as now (either github or local file in the missionzip). I already coded an angelscript CURL helper game.fetchUrlAsStringAsync() so the mission handler can download directly and parsing JSON directly in angelscript is no big deal either. Sorry about bypassing your code this way but as I already blogged, I'm tired of C++ always slowing me down and introducing glitches. The actual AI mode and params must be specified in the .mission file directly though. Then, when actually spawning, the params must be filled to the TopMenubar vars so that the AI.as can read them back. All this is already workable, just not super ellegant.
• An elegant solution to both the points above would be to move the TopMenubar.ai_ vars directly to class VehicleAI and make the AiPanel work directly on top of one VehicleAI object, basically allowing to have multiple of those 'in the works' and eventually serving as a part of a mission editor. This doesn't mean replacing the TopMenubar.ai_ variables with existing VehicleAI variables - they can peacefully live there as "//Staging data", waiting for the VehicleAI object to be "activated" anytime, on spawn or when attached to existing vehicle for flexibility. This would also obsolete game.spawnTruckAI() which is good because like game.spawnTruck() it works outside of message loop, so it's a potential hazzard, and it's already inferior to game.pushMessage(MSG_SIM_SPAWN_ACTOR_REQUESTED, {...}). All that needs to be done is to add a new parameter to the message (the dictionary in angelscript and the underlying ActorSpawnRequest). Don't worry, I'd code all this, or at least lend a hand if you dare so yourself :)

As I said, I'm not requesting any changes right now, just mind-dumping. I'll test and finsh the review later. All in all, you're doing excellent job here. 👍

PS: OMG I have a typo in there: this should be ctc_msg_success. It's not big deal because both are set to the same message, but still. :D