Verify that external copies of boost actually include libraries

[drwells]

This is from the mailing list (hello @labdala). A user managed to 'set up' boost in the following way

#        DEAL_II_WITH_BOOST set up with external dependencies
#            BOOST_VERSION = 1.80.0
#            BOOST_DIR = /nas/longleaf/home/laryssa/dogwood/sfw/linux/boost/boost_1_80_0
#            BOOST_CXX_FLAGS = -Wno-unused-local-typedefs
#            BOOST_DEFINITIONS = BOOST_NO_AUTO_PTR
#            BOOST_USER_DEFINITIONS = BOOST_NO_AUTO_PTR
#            BOOST_INCLUDE_DIRS = /nas/longleaf/home/laryssa/dogwood/sfw/linux/boost/boost_1_80_0
#            BOOST_USER_INCLUDE_DIRS = /nas/longleaf/home/laryssa/dogwood/sfw/linux/boost/boost_1_80_0
#            BOOST_LIBRARIES = /usr/lib64/libboost_iostreams-mt.so;/usr/lib64/libboost_serialization-mt.so;/usr/lib64/libboost_system-mt.so;/usr/lib64/libboost_thread-mt.so;/usr/lib64/libboost_regex-mt.so;/usr/lib64/libboost_chrono-mt.so;/usr/lib64/libboost_date_time-mt.so;/usr/lib64/libboost_atomic-mt.so

by installing just the headers in one location and then CMake picking up the 'missing' libraries from the system copy of boost. We should somehow detect this and try to abort configuration in this case.

[bangerth]

Oh, I failed to see that: The header files are in one directory, and the libraries in another? Yes, this is not likely going to be good...