Add async maple device

[Tails86]

The purpose of this PR is mainly to add maple_async_base for use in a future PR. This base class will allow for asynchronous maple command processing without blocking game emulation. Currently, the std::future is always immediately filled with data, so there is no difference in runtime operation other than the delivery delay is max of each bus delivery delay instead of the total.

I tested asynchronous delays by changing maple_base::output_to_future to:

	std::future<std::vector<u32>> output_to_future(std::vector<u32>&& output)
	{
		return std::async(
			std::launch::async,
			[output]()
			{
				std::this_thread::sleep_for(std::chrono::milliseconds(15));
				return output;
			}
		);
	}

I tested this with delays of 0 ms up to 50 ms with different timeout values in maple_if. There is a hard block for data once that timeout is reached. If that timeout is too high, then data potentially gets lost. If that timeout is too low, then flycast may unnecessarily slow down.

Games start to miss inputs if the timeout and delay are set at or above 25 ms. It generally seemed like gameplay was just fine at a 20 ms timeout with 20 ms processing delay on all commands. I pulled that timeout down to 15 ms to get some headroom because I'd rather have a bit jittery gameplay than missed inputs, and this ensures delivery of data before 1x 60 Hz frame has completed as I know the controller is polled on each 60 Hz frame.

Other notes:

• Delivery of the data must still delay at least as long as the computed transmission delay in maple_if
• Before serialization (save state) can take place, all data must be retrieved from std::future values. I added maple_pre_serialize() to ensure data is loaded into mapleDmaOut before serialization. This is called from mcfg_SerializeDevices()
• I did the same tests with lightgun to ensure SDCKB occupy mechanisms still work, even with delays up to the timeout value, and that seems to be ok

[Tails86]

Gonna close this for now and reopen later if it's needed