Fix "Tag not found" error while looking for a tag's location

[thegavaguy]

In findctag() restore code to actually remove '' from the pattern
buffer. The comment in the function says it is removing backslashes,
but that code was removed during edits around 12/11/2001. This fix
restores the original code except that it avoids copying characters
on top of themselves. Instead, it only begins to copy characters
after encountering a backslash.

[thegavaguy]

The problem occurs when the defining line for a tagged entry has an embedded
slash character or backslash character in the line.

Slash is the default search pattern delimiter for Exuberent Ctags so any slash
character in the line is escaped with a preceding backslash. Typically, for C
or C++ source code files, this means a /* .. */ comment or a // comment. A
backslash is used in C or C++ code in octal character constants or special
escape sequences denoting ASCII control characters. Both slashes and
backslashes need to be escaped when they occur in the search pattern which
defines the location of a tagged entry.

When less is parsing the line from the tag file it needs to strip off the
backslash escape characters, if any, so that it can then do a simple strncmp()
to locate the matching line in the source file. It used to have code to do
this, up until commit fce490b somewhere around 12/11/2001. It is the commit
just before tag v366, which also added the t and T commands to search for tag
results when there is more than one entry for the same tag name.

Part of this commit made wholesale changes to tags.c. The relevant function is
findctag(). It still has the comment indicating that it is stripping off the
backslash, but the code which did the actual modification to the pattern buffer
was removed.

The key part of the findctag() function has not been altered since. At least,
the current revision has the same lines as the version in commit fce490b.

The following command will show all commits that affected tags.c beginning with
the commit which introduced the error:

gitk ^fce490b0 HEAD -- tags.c

The GUI makes it easy to scan through the diffs of the (currently) 33 commits
involved. None of the commits affected the lines in findctag(), although some
of them seem to involve wholesale alterations to whitespace in the source code.
Using git diff -w to disregard whitespace in the creation of the diff output
reduces a lot of the noise in the output.

The command

gitk fe6f7985 fce490b0 -- tags.c

shows all commits, from the root, which involve the tags.c file up to the change
which introduced the bug. Looking through the history of the feature, I elected to restore
the original solution, with one modification. Rather than copying characters on top
of themselves in the common case of there being no escape character (backslash),
I test the two pointers into the line from the tags file for equality and copy
characters only when the pointers are different. In effect, this removes any
escape characters and the updated result then becomes the search pattern.

Note that the more recent addition of the function maketagent() means
that passing a pointer to tagpattern is no longer a problem, since
maketagent() makes a copy of the target string.

I've built and tested an updated less as a 64-bit app using GCC 10
under Msys2 and Microsoft C v19 from Visual Studio 2019 Community Edition,
as these are the platforms I have available.

All tags with backslashes in their search target are now correctly found
by less, as are all tags without backslashes in their search target.

Cheers,
--- GG