Ignore Lints in the Bison/Flex Generated Files

[InsertCreativityHere]

This PR adds NOLINTBEGIN and NOLINTEND markers into the code generated by Bison (Grammar.cpp) and Flex (Scanner.cpp).

Both Bison and Flex support special %code top {...} and %top {...} directives (respectively) which can be used to insert code at the tops of their generated implementations. We're actually already using them to inject copyrights into these files.

Additionally, they support a bottom section (marked by %%). Code in this section is copied verbatim into the generated file.
Some of our files were using this section to define functions, in others I had to add this section.
I made sure to put the NOLINTEND above our function definitions, this means that our functions will still be linted!

---

Some caveats:

1. This doesn't affect the generated Grammar.h file, as Bison exposes no way to generate code at the bottom of this file.
   My understanding is that we're already ignoring the Grammar.h files in our .clang-tidy config file though.
   Note that there is no Scanner.h file to worry about.

2. Flex allows us to generate code at the true tippy-top of it's file, but Bison does not. No matter what Bison, will generate this ahead of our %code top {...}:

/* A Bison parser, made by GNU Bison 3.8.2.  */
/* ... A long doc comment about copyright stuff.  */

/* Identify Bison output, and Bison version.  */
#define YYBISON 30802

/* Bison version string.  */
#define YYBISON_VERSION "3.8.2"

/* Skeleton name.  */
#define YYSKELETON_NAME "yacc.c"

/* Pure parsers.  */
#define YYPURE 1

/* Push parsers.  */
#define YYPUSH 0

/* Pull parsers.  */
#define YYPULL 1

/* "%code top" blocks.  */
#line 1 "src/Slice/Grammar.y"

// Copyright (c) ZeroC, Inc.

// NOLINTBEGIN

These macro definitions do trigger a lint violation about "you should use constants instead of macros here".
There is no way I can see to eliminate this. Tbf, I'm not sure that this is a lint worth checking...

[InsertCreativityHere]

As for the remaining modernize-macro-to-enum lint violations which are unavoidable in Bison.
I think these are pretty safe to ignore. There's nothing inherently wrong with using macro defined constants.

So, personally, I'd rather keep our configuration centralized and opt-out of this lint in our top-level .clang-tidy config file.
But, if others think that this lint is worth checking, we could add .clang-tidy files into just the folders that contain these generated files, where we'd ignore modernize-macro-to-enum.

[bernardnormier]

You didn't put it at the very end because you expect the code below to be lint-free?

[InsertCreativityHere]

Yes, all the code under this line is our code, copied verbatim into the generated file.

I don't expect it to be lint free (but maybe it is). But since it's our code, these are lints that we should be fixing, and not just ignoring!

[externl]

Looks good to me. I'm fine with it in the top level one (with a comment) if we really don't care about this lint for anything else.