ref(gnu-integration): make path optional

[MeredithAnya]

I updated the GNU Integration in #4598 but I didn't make the path optional so if we didn't have the path included, then the stacktrace didn't get parsed:

# got parsed
"17. DB::TCPHandler::runImpl() @ 0x00000000121bb5d8 in /usr/bin/clickhouse"

# didn't get parsed
"17. DB::TCPHandler::runImpl() @ 0x00000000121bb5d8"

So updated it so that regardless of whether the path is present it will get parsed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.09%. Comparing base (0dc5d43) to head (ffffd4b).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4688      +/-   ##
==========================================
+ Coverage   85.04%   85.09%   +0.05%     
==========================================
  Files         156      156              
  Lines       15858    15859       +1     
  Branches     2684     2684              
==========================================
+ Hits        13486    13496      +10     
+ Misses       1589     1584       -5     
+ Partials      783      779       -4     

Files with missing lines	Coverage Δ
sentry_sdk/integrations/gnu_backtrace.py	74.50% <100.00%> (+0.50%)	⬆️

... and 4 files with indirect coverage changes

[seer-by-sentry]

Potential bug: The `FUNCTION_RE` regex is syntactically incorrect, causing compilation to fail. This silently breaks the entire GNU backtrace integration, preventing stacktrace parsing.

• Description: The FUNCTION_RE variable contains a malformed regular expression with an unbalanced parenthesis. When this is formatted into the main FRAME_RE, it results in a regex that cannot be compiled by re.compile. Because this compilation happens inside a capture_internal_exceptions() block, the re.error is caught and suppressed. Consequently, the GNU backtrace integration silently fails to parse any backtraces, leading to a complete loss of this debugging functionality without any warning to the user.
• Suggested fix: The FUNCTION_RE constant is malformed with an extra parenthesis. It should be corrected to r'[^@]+?'. Consequently, FRAME_RE must be updated to explicitly include the address pattern (\s+@\s+0x[0-9a-fA-F]+) and correctly close the function capture group, ensuring the final regex is syntactically valid.
  _{severity: 0.8, confidence: 0.95}

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[sentrivana]

Thank you!