Enhancement: Add Language Server Protocol (LSP) Support

## Summary
Implement Language Server Protocol (LSP) support in Slither to provide real-time security analysis, code intelligence, and interactive feedback directly in developers' IDEs, transforming Slither from a command-line tool to an integrated development companion.

## Motivation

Modern development requires immediate feedback and integrated tooling:

1. **Real-time feedback** - Developers need instant security warnings as they code
2. **IDE integration** - Security tools should work within existing workflows
3. **Interactive analysis** - Hover for explanations, quick fixes for issues
4. **Cross-platform support** - LSP works with VSCode, Vim, Emacs, Sublime, etc.
5. **Incremental analysis** - Only re-analyze changed code for performance

Current limitations of command-line only approach:
- Requires manual execution
- Breaks development flow
- No interactive features
- Delayed feedback on security issues
- Limited context awareness

## LSP Architecture

```
┌─────────────┐ LSP Protocol ┌──────────────────┐
│ IDE │◄────────────────────►│ Slither LSP │
│ (Client) │ │ Server │
└─────────────┘ └──────────────────┘
│ │
│ ▼
▼ ┌──────────────────┐
┌─────────────┐ │ Slither Core │
│ Editor │ │ Analysis │
└─────────────┘ └──────────────────┘
```

## Core LSP Features

### 1. Diagnostics (Real-time Issue Detection)
```json
{
"range": { "start": { "line": 45, "character": 8 }, "end": { "line": 45, "character": 20 } },
"severity": "Warning",
"code": "reentrancy",
"source": "slither",
"message": "Reentrancy vulnerability: State change after external call",
"relatedInformation": [
{
"location": { "uri": "file:///contract.sol", "range": { ... } },
"message": "External call here"
},
{
"location": { "uri": "file:///contract.sol", "range": { ... } },
"message": "State change here"
}
]
}
```

### 2. Hover Information
Provide security insights when hovering over code:
- External call warnings
- Function security properties (can send ETH, can selfdestruct)
- Variable mutability information
- Gas cost estimates

### 3. Code Actions (Quick Fixes)
Offer automatic fixes for common issues:
- Add zero address checks
- Add return value checks
- Apply checks-effects-interactions pattern
- Add reentrancy guards

### 4. Code Lens (Inline Information)
Display inline information above functions/contracts:
- Complexity scores
- Security ratings
- Number of issues detected
- Gas optimization opportunities

### 5. Semantic Tokens
Provide security-aware syntax highlighting:
- Highlight external calls differently
- Mark unsafe assembly blocks
- Identify state-changing operations
- Color-code by security risk level

## Advanced LSP Features

### Custom Commands
```
slither.runFullAnalysis - Run complete analysis
slither.explainVulnerability - Show detailed explanation
slither.generateTestCase - Generate test for detected issue
slither.showSecurityReport - Display comprehensive report
```

### Incremental Analysis
- Cache AST and analysis results
- Only re-analyze affected contracts
- Track dependency changes
- Debounce rapid edits

### Multi-file Analysis
- Build project-wide call graphs
- Track cross-contract vulnerabilities
- Analyze inheritance chains
- Monitor external dependencies

## IDE Integration Example (VSCode)

```json
{
"name": "slither-lsp",
"displayName": "Slither Security Analysis",
"description": "Real-time smart contract security analysis",
"categories": ["Linters", "Programming Languages"],
"activationEvents": ["onLanguage:solidity"],
"contributes": {
"configuration": {
"properties": {
"slither.enable": {
"type": "boolean",
"default": true
},
"slither.detectors": {
"type": "array",
"default": ["all"]
},
"slither.severity": {
"type": "string",
"enum": ["low", "medium", "high", "critical"],
"default": "low"
}
}
},
"commands": [
{
"command": "slither.runAnalysis",
"title": "Run Slither Analysis"
},
{
"command": "slither.showSecurityReport",
"title": "Show Security Report"
}
]
}
}
```

## Implementation Strategy

### Phase 1: Core LSP
1. Implement basic LSP server
2. Add diagnostics support
3. Integrate existing detectors
4. Create VSCode extension

### Phase 2: Enhanced Features
1. Add hover information
2. Implement code actions
3. Add code lens support
4. Semantic token highlighting

### Phase 3: Advanced Integration
1. Incremental analysis
2. Multi-file support
3. Custom commands
4. Project-wide analysis

### Phase 4: IDE Extensions
1. VSCode marketplace release
2. Vim/Neovim plugin
3. Emacs package
4. IntelliJ plugin

## Performance Considerations

- Cache AST parsing results
- Implement incremental analysis for changed files
- Debounce rapid changes (500ms delay)
- Run analysis in background threads
- Limit file size for real-time analysis (1MB default)

## Benefits

1. **Immediate feedback** - Security issues detected as you type
2. **Reduced context switching** - No need to leave IDE
3. **Interactive learning** - Hover for explanations, quick fixes
4. **Improved code quality** - Issues fixed before commit
5. **Better developer experience** - Integrated into natural workflow
6. **Cross-platform** - Works with any LSP-compatible editor

## Configuration

```yaml
lsp:
enabled: true
port: 6969
features:
diagnostics: true
hover: true
code_actions: true
code_lens: true
semantic_tokens: true
analysis:
incremental: true
debounce_ms: 500
max_file_size: 1MB
cache_size: 100MB
detectors:
real_time: ["reentrancy", "unchecked-send"]
on_save: ["all"]
```

## Priority

**High** - LSP support would transform Slither from a periodic analysis tool to a continuous security companion. This matches modern development practices where immediate feedback is expected. The implementation would significantly improve developer productivity and code security by catching issues during development rather than in CI/CD or audits. This is a major differentiator that would position Slither as the leading smart contract security tool for developers.

No files, tests, or entry points are identified. Start by narrowing the proposal to the Phase 1 core LSP scope and reviewing how existing Slither detectors are integrated. Done should be a clearly scoped implementation with diagnostics and a defined integration path, rather than all four proposed phases.

Written by the indexing model from the issue text.