Refactor: Improve UEFI GOP Mode Selection Logic and Configuration

[WgZgYn]

Current Behavior

In the current implementation within uefi/src/main.rs -> init_logger, the GOP (Graphics Output Protocol) mode selection relies on a simple filter-and-last strategy:

modes.filter(|m| resolution_meets_minimum).last()

This approach leads to inconsistent experiences across different environments:

1. Default/Fallback Issue: When no minimum requirements are set, QEMU defaults to a reasonable 1280x800, but my real hardware often falls back to a legacy 800x600 (SVGA), which is insufficient for modern logging.
2. "Last Fit" Bias: When minimum requirements are specified (e.g., 1080p), the code picks the last mode in the list. On high-end displays, this often results in the maximum supported resolution (e.g., 2560x1600 or 3840x2160), which might not be the intended "best" resolution for a bootloader or kernel log.

Proposed Improvement 

I suggest introducing a more robust selection mechanism that supports Preferred Resolutions and Aspect Ratio Filtering. 

1. Predefined Presets: Instead of raw pixel values, allow users to specify common targets like 720p, 1080p, or 2K.
2. Aspect Ratio Awareness: Support filtering by ratios such as 16:9, 16:10, or 4:3.
3. Optimal Selection Strategy:Find the Closest Match to a target resolution.If no exact match exists, fallback to the highest resolution within a specific aspect ratio.Implement a "Best Fit" instead of "Last Fit" (e.g., preference for (1920\times 1080) over (2560\times 1600) if the user targets FHD).
4. Add Maximum Constraint: With only minimum constraints, sometimes it will lead to maximum values. Add maximum constraint to avoid that.
5. EDID: I'm not familiar with UEFI EDID. I know this just form some simple lookup. this might be helpful.

Summary

I think adding maximum constraints and using min_by_key abs_diff or thing else to replace last strategy are easy to implement and solve this problem.

Suggested Labels: enhancement, area/uefi