Add goto Implementation controller (#45)

## Description

This PR adds the new feature `goto Implementation` to the SCIP
controller using reverse implementors index method(ref:
#23)
Tested in company's IDE, ensure the functionality works fine:


https://github.com/user-attachments/assets/d1c21114-c099-49e9-90c0-fd14059dd446



## Type of Change

- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Documentation update
- [ ] Refactoring (no functional changes)
- [ ] Performance improvement
- [ ] Test improvement

## Component(s) Affected

- [x] Language Server (ULSP)
- [ ] SCIP Generation (Python utilities)
- [ ] VS Code/Cursor Extension
- [ ] Java Aggregator
- [ ] Build System (Bazel)
- [ ] Documentation
- [ ] Tests

## Testing

- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes (`bazel
test //...`)
- [x] I have tested this manually with a real project

### Manual Testing Details

Describe how you tested these changes:
- IDE used for testing:
- Project(s) tested against:
- Specific features/scenarios verified:

## Checklist

- [x] My code follows the existing code style and conventions
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have made corresponding changes to the documentation
- [x] I have updated BUILD.bazel files if I added new source files
- [x] My changes generate no new warnings
- [x] Any dependent changes have been merged and published

## Screenshots/Logs (if applicable)

Include any relevant screenshots, logs, or output that demonstrates the
changes.

## Related Issues

Fixes #(issue number)
Closes #(issue number)
Related to #(issue number)

## Additional Notes

Any additional information that reviewers should know about this PR.

refactor(scip): separate out files in mapper that depends on proto to…

… another directory (#31)

## Description
Move all functions under `src/ulsp/mapper` that touch proto code into a
separate sub-package, `src/ulsp/mapper/idl`.
This way:
`src/ulsp/mapper` only contains logic for LSP, JSON-RPC, and general
mapping.
`src/ulsp/mapper/idl` contains the parts that translate between internal
models and protobuf messages.
When a controller imports mapper, no proto code is compiled in.
Only code that explicitly imports mapper/idl will depend on the
generated .pb.go files.
So that it won't cause `proto: duplicate proto type registered:` error
log when importing `github.com/uber/scip-lsp/src/ulsp/controller/scip`
due to importing two versions of the same proto file that may conflict
with each other

Also checked build graph:
```
$ bazel query "somepath(//src/ulsp/controller/scip:go_default_library, //idl/...)" 
INFO: Empty results
```
## Type of Change

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Documentation update
- [x] Refactoring (no functional changes)
- [ ] Performance improvement
- [ ] Test improvement

## Component(s) Affected

- [x] Language Server (ULSP)
- [ ] SCIP Generation (Python utilities)
- [ ] VS Code/Cursor Extension
- [ ] Java Aggregator
- [ ] Build System (Bazel)
- [ ] Documentation
- [ ] Tests

## Testing

- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes (`bazel
test //...`)
- [x] I have tested this manually with a real project

### Manual Testing Details

Describe how you tested these changes:
- IDE used for testing:
- Project(s) tested against:
- Specific features/scenarios verified:

## Checklist

- [x] My code follows the existing code style and conventions
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] I have updated BUILD.bazel files if I added new source files
- [ ] My changes generate no new warnings
- [ ] Any dependent changes have been merged and published

## Screenshots/Logs (if applicable)

Include any relevant screenshots, logs, or output that demonstrates the
changes.

## Related Issues

Fixes #(issue number)
Closes #(issue number)
Related to #(issue number)

## Additional Notes

Any additional information that reviewers should know about this PR.

downgrade testify in go mod (#30)

## Description

Downgrade github.com/stretchr/testify to v1.10.0 so that when importing
scip-lsp in other repo there will not cause compatibility issue.

## Type of Change

- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Documentation update
- [ ] Refactoring (no functional changes)
- [ ] Performance improvement
- [ ] Test improvement

## Component(s) Affected

- [ ] Language Server (ULSP)
- [ ] SCIP Generation (Python utilities)
- [ ] VS Code/Cursor Extension
- [ ] Java Aggregator
- [ ] Build System (Bazel)
- [ ] Documentation
- [x] Tests

## Testing

- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes (`bazel
test //...`)
- [x] I have tested this manually with a real project

### Manual Testing Details

Describe how you tested these changes:
- IDE used for testing:
- Project(s) tested against:
- Specific features/scenarios verified:

## Checklist

- [ ] My code follows the existing code style and conventions
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] I have updated BUILD.bazel files if I added new source files
- [ ] My changes generate no new warnings
- [ ] Any dependent changes have been merged and published

## Screenshots/Logs (if applicable)

Include any relevant screenshots, logs, or output that demonstrates the
changes.

## Related Issues

Fixes #(issue number)
Closes #(issue number)
Related to #(issue number)

## Additional Notes

Any additional information that reviewers should know about this PR.

fixup! tidy go deps (#26)

## Description

Updates the go dependecies to get rid of some stale items; Move to
tally/v4 for build errors.

## Type of Change

- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Documentation update
- [ ] Refactoring (no functional changes)
- [ ] Performance improvement
- [ ] Test improvement

## Component(s) Affected

- [x] Language Server (ULSP)
- [ ] SCIP Generation (Python utilities)
- [ ] VS Code/Cursor Extension
- [ ] Java Aggregator
- [ ] Build System (Bazel)
- [ ] Documentation
- [ ] Tests

## Testing

- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes (`bazel
test //...`)
- [x] I have tested this manually with a real project

### Manual Testing Details

Describe how you tested these changes:
- IDE used for testing:
- Project(s) tested against:
- Specific features/scenarios verified:

## Checklist

- [ ] My code follows the existing code style and conventions
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] I have updated BUILD.bazel files if I added new source files
- [ ] My changes generate no new warnings
- [ ] Any dependent changes have been merged and published

## Screenshots/Logs (if applicable)

Include any relevant screenshots, logs, or output that demonstrates the
changes.

## Related Issues

Fixes #(issue number)
Closes #(issue number)
Related to #(issue number)

## Additional Notes

Any additional information that reviewers should know about this PR.