Implement rover as access point and compare latency

[Ezward]

Why
As discussed in issue #8, we would like to reduce the video latency between the rover and the gamepad in order to make FPV mode more usable. One potential latency is the protocol between the rover and the web application. The Open.HD project has addressed this issue in part by writing code to create a custom peer to peer connection between RaspberryPi endpoints using usb wifi adapters' radios. Espressif had created a similar peer to peer protocol between Esp32 endpoints called EspNow. However, EspNow is not suitable for transferring video because it limits a message to 250 bytes. Instead, we would like to see if removing the router from our current setup reduces latency.

Our current wifi setup configures the rover's Esp32Cam as a wifi station that connects to a wifi access point. The client also connects to that wifi access point, then uses the Esp32Cam's ip address to load the web application. This presents two issues; first we have to know that ip address that the router assigned to the Esp32Cam. Second and more importantly to this ticket, websocket packets must transit the wifi router to get from rover to client browser. We want to see if removing that wifi router from the middle can reduce latency. As a potential side benefit, it may simplify connecting to the rover.

What
Implement a wifi configuration where the rover's Esp32Cam is configured as an access point. The device that will run the web browser will then connect directly to that access point. This will eliminate the intervening wifi router. Note we may need to implement a wifi configuration where the rover's Esp32Cam is both an access point and a station, so that it can serve the web application, serve the camera status endpoints and join the websocket connection.

Once this configuration is working, measure the video latency between the rover and the web client.