Intern import details/metadata line contents

[Peter554]

In this PR:

1. I've updated the large graph fixture to include line number and line contents. This makes the test_copy_graph benchmark much more realistic. This does lead to a regression in the benchmarks, but this regression is expected since now the graph object is much bigger.
2. I've interned the line contents (similar to the interning of the module name). This gives a significant boost to the performance of copying the graph. This is helpful, since in import-linter we always copy the graph before passing it to a contract.
3. I've also done the renaming that was suggested: name -> interned_name, name_as_string -> name.

Since change 1. gives a performance regression, as compared with the benchmark on master, here are the benchmark results run locally comparing the 1st commit (add line contents to large graph fixture) with the last commit (interned line contents). This shows that the changes in this PR gives ~2.5x improvement to the graph copy.

------- benchmark 'test_copy_graph': 2 tests -------
Name (time in ms)                     Mean
----------------------------------------------------
test_copy_graph (NOW)              11.1924 (1.0)
test_copy_graph (0158_4d701e8)     27.8061 (2.48)
----------------------------------------------------

[codspeed-hq]

CodSpeed Performance Report

Merging #185 will degrade performances by 46.5%

_{Comparing Peter554:faster-graph-clone (ae3ea3d) with master (830ce44)}

Summary

❌ 1 (👁 1) regressions
✅ 16 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
👁	test_copy_graph	43.1 ms	80.5 ms	-46.5%

[Peter554]

This change introduces a regression in the benchmark for test_copy_graph, but this is reasonable since now the graph object is much bigger!

[Peter554]

This gives a small but measurable performance benefit. I think people aren't really having import statements past line 65535 😅

[seddonym]

I agree with the change - but I can believe there are modules out there in the wild that get that big. How would Grimp behave if it did encounter such a module?

Ideally we should handle it gracefully, but as long as we have the new behaviour captured in a ticket, and the change mentioned in the CHANGELOG, I'm happy.

[Peter554]

How would Grimp behave if it did encounter such a module?

Yes maybe it's worth a bit of thought.

It's quite a micro-optimisation anyways, so I think instead I'll just opt to use u32 here instead - I'm near certain that nobody will overflow that!

[Peter554]

(With u32 I wouldn't update the changelog)

[seddonym]

I'm near certain that nobody will overflow that!

Agreed 😄

[seddonym]

Good stuff - I think the change to line_number needs at least a mention in the CHANGELOG though, would you mind adding that?

[seddonym]

I agree with the change - but I can believe there are modules out there in the wild that get that big. How would Grimp behave if it did encounter such a module?

Ideally we should handle it gracefully, but as long as we have the new behaviour captured in a ticket, and the change mentioned in the CHANGELOG, I'm happy.