Add --no-private-id-locs and new NEW_ID macro

[widlarizer]

This PR adds a new option named --no-private-id-locs that prevents users of the new version of NEW_ID and NEW_ID_SUFFIX from adding Yosys C++ source file locations to automatic design object names.

$ yosys -p "read_verilog add.v; synth; dump" | grep auto | tail -n1
  cell $_XOR_ $abc$192$auto$blifparse.cc:397:parse_blif$232
$ yosys --no-private-id-locs -p "read_verilog add.v; synth; dump" | grep auto | tail -n1
  cell $_XOR_ $abc$192$auto$?:0:?$232

The old macros still work the same way as before and now give a deprecation warning. The new macros are named NEWER_ID and NEWER_ID_SUFFIX, NEW_ID2 and NEW_ID_SUFFIX2 are an option as well. #5315 benefits from this feature, reducing the proportion of PRs that require an update of the reference RTLIL dump for its synth -noabc result stability test. Sorry for the reviewer spam. I'm removing that test to decouple things and reduce test maintenance

• Add test

[jix]

I like the idea for reducing a source of noise, (although not so much the idea of having two sets of macros), but this also makes me wonder whether there's also a related performance benefit:

Could we make this the unconditional default and have a runtime opt-in to track yosys source locs that doesn't affect the generated IdStrings but rather uses some out of band dict<IdString, ...> to optionally store source locs and any NEW_ID_SUFFIX arguments? Would that allow us to entirely avoid string allocation and hashing for autoidx private ids? Not sure yet if that would all come together nicely, but seems worth thinking through.