dylan-bt needs to distinguish methods with same name

[cgay]

From the example backtrace I'm about to add to the getting-started-cli doc:

   (lldb) dylan-bt
     frame #1    invoke-debugger        0x007ffff7d43da9 libdylan.so at boot.dylan:1041
     frame #3    default-handler        0x007ffff7d52bc2 libdylan.so at condition.dylan:140
     frame #5    default-last-handler   0x007ffff7f7ee5d libcommon-dylan.so at common-extensions.dylan:448
     frame #7    error                  0x007ffff7d52743 libdylan.so at condition.dylan:125
     frame #9    error                  0x007ffff7d52716 libdylan.so at condition.dylan:154
     frame #10   bar                    0x007ffff7fb0214 libdebugging.so at debugging.dylan:22

That should say

   (lldb) dylan-bt
     frame #1    invoke-debugger        0x007ffff7d43da9 libdylan.so at boot.dylan:1041
     frame #3    default-handler        0x007ffff7d52bc2 libdylan.so at condition.dylan:140
     frame #5    default-last-handler   0x007ffff7f7ee5d libcommon-dylan.so at common-extensions.dylan:448
     frame #7    error(<condition>)     0x007ffff7d52743 libdylan.so at condition.dylan:125
     frame #9    error(<string>)        0x007ffff7d52716 libdylan.so at condition.dylan:154
     frame #10   bar                    0x007ffff7fb0214 libdebugging.so at debugging.dylan:22

i.e., frames 7 and 9 should show the required argument types.

[cgay]

This case makes the problem even clearer:

  error:dylan:dylan##0 + 0x27
  type-check-error:internal:dylan + 0x6d
  emit:protocol-buffers-impl:protocol-buffers##3 + 0xbc
  emit:protocol-buffers-impl:protocol-buffers##2 + 0x1f1
  emit:protocol-buffers-impl:protocol-buffers##1 + 0x206
  main:pbgen:pbgen + 0xbb

could instead be something like this:

  error:dylan:dylan##0 + 0x27
  type-check-error:internal:dylan + 0x6d
  emit(<generator>,<enum-descriptor-proto>):protocol-buffers-impl:protocol-buffers##3 + 0xbc
  emit(<generator>,<descriptor-proto>):protocol-buffers-impl:protocol-buffers##2 + 0x1f1
  emit(<generator>,<file-descriptor-proto>):protocol-buffers-impl:protocol-buffers##1 + 0x206
  main:pbgen:pbgen + 0xbb

Admittedly these stack frame names could get really long in some cases, but it's better than not knowing where the error is occurring. (I guess line numbers would be a work-around too, but really we need both.)

And I guess ideally the backtrace generator is smart enough to know it doesn't have to distinguish two frames based on argument types unless there are two frames for the same generic function.