fixed header file could not be found and removed redundant declarations

[L-Super]

1. fixed some scenarios where the header file could not be found
2. removed redundant declarations

[tishion]

@L-Super 感谢你提交的PR，但是抱歉这个PR不符合设计原则。

1. PR删除了#ifndef语句，只保留了#pragam once，看起来是冗余，但是#pragma once是从MSVC编译器诞生的，其他编译器对这个预编译指令的支持并不是全版本支持的，所以这样写是为了保证兼容性（虽然现在几乎所有编译器的最新版本都已经支持了，我还是希望保留这这种写法）
2. 任何第三方库的public header中都不应该包含用“”来引用的头文件，如果有，那就是这个三方库做的不够专业。C++由于语言的特性，在依赖管理方便相比其他语言来说是比较复杂的，但是头文件引用这方面也是既定规则的，
   • 通过<>引用的头文件，编译器会尝试在编译配置选项中指定的include目录中搜索，不会在当前编译单元的相对路径中搜索
   • 通过“”引用的头文件，编译器会首相尝试编译选项配置中指定的include目录中搜索，然后再当前编译单元的相对路径中搜索 一个设计良好的第三方C++库，对外提供支持主要依靠头文件和二进制（static lib或者dynamic lib），对外提供的头文件目录设计原则是作为一个整体对外提供，用户只需要在自己的的项目中把三方库的include目录加入项目配置中，就能保证正确编译。 所以一个三方库在对外的public header中全部统一使用<>来互相引用，是为了强调这些头文件作为三方库的完整性，并且不属于使用这个三方库的项目这一原则。

这个PR唯一值得该动的地方是这里： https://github.com/CefView/QCefView/blob/5fd7da61cda60277735d610aec0478b40cd0b7bd/include/QCefContext.h#L9-L10

这里手误写错了，你可以把这了更正一下，除此之外，请全部revert。

[L-Super]

对于第一点，项目里cmake的最低C++要求为14，那这里的预编译出于旧式编译器的兼容是否又相矛盾呢？ 对于第二点，是由于在使用中遇到了未找到头文件的问题，将其改为""方式便能成功编译。还有就是，我参考了很多库，ffmpeg、leveldb，以及已经进入C++20标准的fmt库，他们都是采用的""方式，而非<>方式。当然，这取决于库作者自身，我的PR顶多只能算锦上添花。

[tishion]

对于第一点，项目里cmake的最低C++要求为14，那这里的预编译出于旧式编译器的兼容是否又相矛盾呢？ 对于第二点，是由于在使用中遇到了未找到头文件的问题，将其改为""方式便能成功编译。还有就是，我参考了很多库，ffmpeg、leveldb，以及已经进入C++20标准的fmt库，他们都是采用的""方式，而非<>方式。当然，这取决于库作者自身，我的PR顶多只能算锦上添花。

1. 这一点我们就不深入讨论了，应该是我们开始编程的时代不同，所以习惯不一样，但是我能保证的就是我留在项目中的习惯都是有益无害的。
2. 先说你遇到的问题，使用第三方库的时候，以windows 平台的构建工具来距离，标准的做法是把该库的头文件目录添加到solution级别的include directories或者project级别的include directories（无论哪个级别，通过CMake都可以很容易做到），这样做，无论三方库内部使用“”还是<>，你的项目都不会出现找不到头文件的问题，如果出现了，那就是三方库的头文件自身有问题。
3. 至于你列举的例子，是流行并且独一无二的优秀库，但是他们只是少数不在乎是否严格强调C/C++头文件引用方式的作者，绝大部分开源库并不是他们这样做的，boost，Qt，去VCPKG库里看看就应该明白了。（ffmpeg是C语言实现，在目录结构上除了大模块划分之外，并没有额外的设计思维存在（仅仅是说项目目录结构））。