std::string_view is a great addition to the standard. It provides a great and cheap way to pass const strings around that could come from a std::string, from a c string or even from some in-memory buffer that doesn't even have to be null terminated.

I noticed there was an attempt to add usages of this type in #2847 by checking in a macro for 17. However, since this still is C++11 library, this poses some problems:

1. Firstly, the obvious one that I'm the most concerned about is that for builds made on C++11 and C++14 there is still the unnecessary string copy that compilers can't yet optimize out.
   For the ANTLRInputStream class, even if it has a constructor that takes const char*, size_t that looks like it doesn't make a copy, that actually creates a std::string and it passes down to the other constructor. So even on a C++17 build this class is not saved from extra copies.

2. As someone pointed out in another PR, this creates 2 separate ABIs for the library, making it impossible to link antlr built with 17 and a binary built with 11 or vice versa.

3. This significantly reduces the ability detect compilation errors and/or runtime errors without building and running tests with the library compiled with both 17 and pre-17.

The solutions that I thought of involve replacing std::string_view with a substitute or removing it at all. This can be done because std::string_view doesn't use any language feature introduced in 17.

1. string-view-lite looks like a full implementation of string_view and can be configured to not use std::string_view even when building with 17 in order to not break ABI again.

2. string_view is a trivial class to implement and so far it doesn't look like Antlr will need anything more the constructors, .size() and .data(). One can implement a small StringView that can be embedded directly in this project.

3. Maybe it would be a good idea to take a step back and just provide overloads that take const char*, size_t for any constructor/method that doesn't copy the input string and remove string_view altogether.

To be fair, I am not a big fan of the last suggestion. I think either suggestion 1 or 2 would be a good fit for the project, but I like 2 the most.

What do you think about this?