Eliminate vtr_free and vtr_malloc/vtr_calloc/vtr_realloc

[SamuelHo10]

Replaced most of the free/malloc/calloc with new/delete in ArchFPGA library. I left a few unchanged because they either conflict with vtr::strdup or are used by other libraries such as VPR or Odin. This is my first pull request, so please let me know if I am forgetting anything.

[soheilshahrouz]

Thanks @SamuelHo10

I left a few comments suggesting how the code can be improved in future PRs.

[vaughnbetz]

Thanks for starting the cleanup on this @SamuelHo10 .
I think some of these changes are unsafe in isolation though ... see my comments on calloc and default constructors. I think we need to write default constructors for the structs in question to be able to safely use new instead of calloc.
We should also take this as an opportunity to get rid of some complexity in the code and simplify memory management by moving to std:: container classes like vectors as @soheilshahrouz suggested. I think you should take this changes a little at a time though, running tests (or pushing to CI to have it run tests) frequently, and committing intermediate cleanups at each working stage.

We could discuss in person next week what good stages are.

[vaughnbetz]

We could probably change this linked list (which currently stores pb_type* pointers) to a vector of pb_type* (or maybe even just to direct pb_type elements). Probably don't do that yet though ... we should refactor in stages.

[vaughnbetz]

It might be good enough to use = default to explicitly ask for default constructors, as I believe in that case all built-in type data members are initialized to 0 (e.g. int, float, etc.). That would only be a few lines of code, but you should test to be sure I'm right about the behaviour of that.
C++ has messed around a bit with the behaviour of constructors over the years, which is why the =default seems to change the behaviour of compiler-built default constructors.

[soheilshahrouz]

Why is this a shared_ptr? Do we have multiple copies of this pointer? If not, I think unique_ptr would be a better choice.

[SamuelHo10]

It is shared by device_ctx.clock_arch. I think @vaughnbetz mentioned that in the future, we should get rid of the pointer entirely by assigning the value to device_ctx.clock_arch at the end. Currently, the code is creating two pointers with the same memory address and assigning a value after which can be dangerous.

[SamuelHo10]

I've just realized that during the build process, I am getting warnings of the form:

warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
737 | mem_pb_type->modes[0].interconnect = new t_interconnect[mem_pb_type->modes[0].num_interconnect];

I'm pretty sure this is most likely caused by the fact that I haven't casted int to size_t, even though it still pasts all of the tests. Should I properly cast everything?