feat: change DebugSession::source_by_path() to return SourceCode enum

[vaind]

closes #735 - this changes DebugSession::source_by_path() to return one of two options, a real source code, or an http source link.

This is a breaking change so will require a new major version.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against b947346

[codecov]

Codecov Report

Merging #758 (4ed61c5) into master (9f7ceef) will increase coverage by 0.28%.
The diff coverage is 92.06%.

❗ Current head 4ed61c5 differs from pull request most recent head b947346. Consider uploading reports for the commit b947346 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #758      +/-   ##
==========================================
+ Coverage   73.90%   74.19%   +0.28%     
==========================================
  Files          69       70       +1     
  Lines       14952    15112     +160     
==========================================
+ Hits        11051    11213     +162     
+ Misses       3901     3899       -2     

[loewenheim]

Thanks for doing this!

[Swatinem]

I believe there is only ever one module as defined in the specification.

[mitsuhiko]

Don't take this as blocking the merge but I think it might be sensible to think about this a bit more. These thoughts came to mind:

• DWARF5 already has a way to refer to source code by MD5 (DW_LNCT_MD5) which could be used for a symbol server to look up sources
• There are extensions to DWARF5 to embed source directly (Support DW_LNCT_LLVM_source gimli-rs/gimli#431)

This to me implied there are multiple ways to refer to source, some of which might exist concurrencly. I wonder if it makes sense to revisit this abstraction. If we do decide that the return value is an enum and you gotta deal with it there, then we should make this #[non_exhaustive] since we probably expect more things to be added in the future.

[vaind]

Thanks @mitsuhiko, I've added the attribute.