Make sure #240 (class name instead of file name) did not break future integration with Elastic code search

[SergeyKleyman]

Derived from #240 (comment)

[axw]

From the linked PR:

@axw Do you think the planned integrations will use information sent by agent as part of error stack trace?

Yes, definitely. VCS info + filename + line number gives us sufficient information to link to code. We could do the same with assembly + class + method name, but that requires semantic code analysis, whereas filename + line does not.

Let's please keep the field definitions consistent across agents: the filename field should hold the filename, and not the class name. We can potentially change how we render the stack frames in the UI, but changing the meaning of the data is going to lead to problems down the line.

For reference, here's what the Go agent records in stack frames:

• absolute path is the absolute file path, which may or may not be available (could be stripped from the binary), e.g. "/my/source/path/tracer.go"
• filename is the filename, e.g. "tracer.go"
• line is the line number, e.g. 42
• module is set to the package path, e.g. "go.elastic.co/apm"
• function is the function or method name, e.g. "TopLevelFunction" or "SomeType.MethodName"

For .NET, I think the only thing I'd change would be to set module to the namespace, like "System.Net.Http".

[gregkalapos]

Closing due to changes in code search.