TFLITE fix inconsistencies in using std/absl for variant/any_cast functions.
Here are the internal errors, @radekzc can you please verify ? Thank you!

ld: error: undefined reference due to --no-allow-shlib-undefined: util_graphics_giza::BlendRgbaToRgbaIcon::DrawScanlines(int, int, int, int, int, util_graphics_giza::GizaOperator, Callback5<int, int, int, unsigned int, util_graphics_giza::GizaOperator>*) const
>>> referenced by blaze-out/k8-opt/bin/_solib_k8/libutil_Sgraphics_Sgiza_Sinternal_Slibgiza.ifso

ld: error: undefined reference due to --no-allow-shlib-undefined: util_graphics_giza::BlendRgbaToRgbaIcon::DrawIntoIndexcolorBuffer(int, int, int, int, int, int, unsigned char const*, unsigned char*) const
>>> referenced by blaze-out/k8-opt/bin/_solib_k8/libutil_Sgraphics_Sgiza_Sinternal_Slibgiza.ifso

ld: error: undefined reference due to --no-allow-shlib-undefined: util_graphics_giza::BlendRgbaToRgbaIcon::DrawIntoRgbaBuffer(int, int, int, int, int, int, util_graphics_giza::GizaOperator, unsigned char*) const
>>> referenced by blaze-out/k8-opt/bin/_solib_k8/libutil_Sgraphics_Sgiza_Sinternal_Slibgiza.ifso
clang: error: linker command failed with exit code 1 (use -v to see invocation) Seems not relevant to the commit. Hi @radekzc,

Could you provide the steps to reproduce the issue (breakages under Windows build)? Will try to prepare minimal example, but it may take time. 

If you are unsure what this PR fixes, its like if you wrote code like

```
int * a = new int;
...
free(a);   // free instead of delete
```

which would "work" if the compiler used

```
void free(void *ptr)
{
    delete(ptr);
}
```

which is often the case, but there is zero guarantee it works always, because the behavior is undefined.




 Hi @radekzc Any update on this PR? Please. Thank you! Hi @radekzc,

According to Google's policy, we are deprecating the usage of absl::any_cast and absl::variant in our codebase. To avoid the scenario you mentioned, Is it ok to fix all uses of absl::variant/any_cast to std::variant/any_cast? Yes, perfectly ok. Hi @radekzc Any update on the above [comments](https://github.com/tensorflow/tensorflow/pull/60797#issuecomment-1690990772)? Please. Thank you! Hi @radekzc Any update on the above https://github.com/tensorflow/tensorflow/pull/60797#issuecomment-1709240974? Please. Thank you! Hi @radekzc Any update on the above https://github.com/tensorflow/tensorflow/pull/60797#issuecomment-1709240974? Please. Thank you! Hi @radekzc Any update on the above https://github.com/tensorflow/tensorflow/pull/60797#issuecomment-1709240974? Please. Thank you! Hi @radekzc Any update on the above https://github.com/tensorflow/tensorflow/pull/60797#issuecomment-1709240974? Please. Thank you! Hello
Please also delete 
#include <variant> 
on top of header
"tensorflow/lite/delegates/gpu/common/operations.h"

It's broking builds with old compilers (require c++17). 
 > Hello Please also delete #include on top of header "tensorflow/lite/delegates/gpu/common/operations.h"
> 
> It's broking builds with old compilers (require c++17).

Based on previous comments the agreed upon way is to completely remove absl and switch to std instead, which is the direct opposite of this commit. I can look into this when our next backend upgrade task (switching to newer TF version in our product) begins, which is due in April. If the absl/std hell still exist, I will refactor it to std and sent a new pull request.
Fix using std::any_cast instead of absl::any_cast

Inconsistencies exist in Lite repo using std::variant/absl::variant and std::any_cast/absl::any_cast. When abseil is built with ABSL_USES_STD_ANY (Linux), everything works even with this bug. But if not (on Windows build), this uses std::any_cast on variable created by absl::variant, causing a throwing of exception at runtime.