`combinedef` could/should yield better line numbers

### Motivation and description

Consider this macro, that defines both `f` as is and `f_5` via `combinedef`

```julia
julia> macro return_5(fdef)
di = splitdef(fdef)
di[:name] = Symbol(di[:name], :_5)
di[:body] = quote for _ in 1:5 end; 5 end
return esc(quote
$fdef
$(combinedef(di))
end)
end
@return_5 (macro with 1 method)
```

The uncombined method (`bar`) has correct line number, but the `bar_5` method has a line number from the `macro return_5` (it's the `di[:body]` line). This ruins "Go to definition" features. The user wants to go to `bar_5` but gets taken to `macro return_5`.

```julia
julia> @return_5 bar(x) = x+10
bar_5 (generic function with 1 method)

julia> methods(bar)
# 1 method for generic function "bar" from Main:
[1] bar(x)
@ REPL[18]:1

julia> methods(bar_5)
# 1 method for generic function "bar_5" from Main:
[1] bar_5(x)
@ REPL[17]:4
```
This can be solved by using `@qq begin` instead of `quote`, but A) most people don't know about it and B) `@qq` is a bit of a blunt tool.

### Possible Implementation

1. Find the `LineNumberNode` in `splitdef`
2. Store it inside of the dict returned by `splitdef`
3. Insert it in the new method in `combinedef`

The `LineNumberNode` seems to always be the first element of the body's `block`. It shouldn't be too difficult.
```julia
julia> dump(:(f(x) = x+2))
Expr
head: Symbol =
args: Array{Any}((2,))
1: Expr
head: Symbol call
args: Array{Any}((2,))
1: Symbol f
2: Symbol x
2: Expr
head: Symbol block
args: Array{Any}((2,))
1: LineNumberNode
line: Int64 1
file: Symbol REPL[30]
2: Expr
head: Symbol call
args: Array{Any}((3,))
1: Symbol +
2: Symbol x
3: Int64 2
```

Start by reading the splitdef and combinedef implementations and inspect how the function body’s LineNumberNode is represented. Use the @return_5 example to verify that the generated bar_5 method points to the original definition’s line rather than the macro body, while bar remains correct.

Written by the indexing model from the issue text.