set of windows (mingw64) build fixes

[w0lek]

There are a couple compilation fixes for mingw64 build

Description

Two kind of changes:

1. removed unused function

char* getline(char*& _lineptr, FILE* _stream)

This function has compilation issue and is not actually used and looks obsolete.
If removing is not an option, i will think how to correct code without removing it.

2. #define _USE_MATH_DEFINES for _WIN32 platform to ensure (non-standard) value of M_PI is brought in from math.h

Related Issue

#3076

Motivation and Context

Allows to build application on windows platform using mingw64

How Has This Been Tested?

It was tested as a part of hotfixes for a several releases in Aurora package (windows build)

Types of changes

• Compilation errors
• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[AmirhosseinPoolad]

Thanks for the PR @w0lek. regarding the getline function, even if it wasn't unused I fully support removing it. Seems like a relic from the old C days.

Other than that I had a suggestion on a way to avoid ifdefs for windows compatibility.

[AmirhosseinPoolad]

libezgl doesn't actually belong to this repository and is a subtree here. The actual repo for it is here:
https://github.com/verilog-to-routing/ezgl

However, we're going to sync up the two repositories really soon so I think it's okay to do the change here. @AlexandreSinger thoughts?

Also if ezgl is compiled with C++20, see below on a way to avoid doing ifdefs.

EDIT: Just checked and it's C++14.

[AlexandreSinger]

If this PR can come in before we change this to a sub-module it should be fine (we can include it with the other changes that need to be brought in); if not, @w0lek would need to raise a PR on the EZGL repo (which we will immediately accept).

I think EZGL is kept on C++14 to ensure that it builds on the school computers for the coarse it is used in (but thats just a guess). C++20 is still technically experimental and some of the features confuse students, so we keep them on C++14 if I recall correctly. I see no issue with this fix for now.

[AmirhosseinPoolad]

C++20 has added std::numbers::pi (double) and std::numbers::pi_v which should fix this problem and would be cleaner. I'm not sure if ezgl is compiled with C++20 but it can definitely be used here.