configure: fall back to brew for lpeg detection on macOS

[erf]

Summary

On macOS with Homebrew, ./configure fails to detect lpeg for static linking because Homebrew's lpeg package does not ship a pkg-config file or install liblpeg into the default linker search path.

This adds a fallback that uses brew --prefix lpeg to locate the library when the existing pkg-config and -l flag detection methods both fail.

Problem

Running ./configure && make && sudo make install on macOS with Homebrew-installed lpeg results in vis being built without lpeg support. At runtime, require('lpeg') fails because Lua's package.cpath doesn't include the Homebrew Cellar path (especially after a Lua version upgrade, e.g. 5.4 -> 5.5), and syntax highlighting is broken:

/usr/local/share/vis/lexers/lexer.lua:862: module 'lpeg' not found

The root cause is that the configure script only tries:

1. pkg-config with names: lpeg, lua5.5-lpeg, etc. — Homebrew has no .pc file for lpeg
2. Bare -llpeg — Homebrew installs liblpeg.dylib under its Cellar, not in /opt/homebrew/lib/

Fix

After the existing detection loop, if lpeg was not found and brew is available, try brew --prefix lpeg to get the library path and link against it. This is consistent with how Homebrew packages are designed to be discovered. The fallback only runs when the existing methods fail, so it has no effect on Linux or non-Homebrew systems.

Testing

Verified with Homebrew's lpeg unlinked (simulating fresh install state):

• ./configure — auto mode finds lpeg via brew fallback
• ./configure --enable-lpeg-static — explicit mode finds lpeg via brew fallback
• ./configure --disable-lpeg-static — correctly skips lpeg entirely
• make succeeds with CONFIG_LPEG=1

[erf]

Note: This patch was written with the help of an AI coding assistant. It has been tested locally on macOS with Homebrew, but I'd appreciate any feedback on whether the approach is appropriate for the project.

[rnpnr]

Note: This patch was written with the help of an AI coding assistant. It has been tested locally on macOS with Homebrew, but I'd appreciate any feedback on whether the approach is appropriate for the project.

As far as I'm concerned its completely unreasonable to assume that every contribution from an "ai agent" will be marked as such. These contributions will be reviewed and held to the same standard as any other contribution. That means no irrelevant or incorrect comments, no "predefined" code snippets (I mean the kind of thing that is copy-pasted from stack overflow for example), amongst more fundamental things like introducing terrible design/architecture because it prevalent all over the training dataset. If people continue to reject things based solely on the fact that it contains "ai contributions" it will just change the incentive structure so that the people submitting those patches will find more ways to obfuscate their "ai" usage.

I'm not noticing any of those issues with this PR, but I would say that the PR text itself is way too much for such a small change. The summary section on its own would have been fine. I will merge it unless someone else raises any concerns.

[rnpnr]

Sorry, I didn't mean to leave this for so long. Thanks for the patch!