Consider loading `libEGL.so.1` instead of `libEGL.so`

[mukilan]

After the GStreamer update in Servo, the nightly binaries have been failing to launch on linux distros unless libegl1-mesa-dev or equivalent package is installed in the runtime environment.

Based on my investigation here, it seems the root cause of the failure is that surfman is trying to dynamically open and load functions from libEGL.so, but on many systems the symlink from libEGL.so to the versioned shared object i.e libEGL.so.1 doesn't exist unless the libegl1-mesa-dev or equivalent package is installed.

Also, the reason the binaries were loading before the GStreamer update was because the binary had a compile-time link to libEGL.so.1 (due to gstreamer-sys crate, which on nightly is not present after the GStreamer upgrade since we have also disabled the media stack). Because of this compile time link, the dlsym calls are able to succesfully load the functions even though the dlopen('libEGL.so') call returns a null handle, indicating failure.

Additionally, @mrobinson found this issue which indicates other bindings like khronos-egl load libEGL.so.1 instead of libEGL.so.

This issue is to decide if it is a good idea to do the same in surfman. I don't have expertise in EGL, so I am not sure if we still need a fallback to loading libEGL.so if libEGL.so.1 fails to load, like khronos-egl does. I have tested with a patched surfman that loading libEGL.so.1 does indeed fix the egl function was not loaded issues and Servo continues to work.