fix(test): avoid overriding the configured C++ standard

[zchuango]

What problem does this PR solve?

Issue Number:
Problem Summary:

When bRPC is configured with Protobuf 22 or newer, config_brpc.sh selects C++17 because the accompanying Abseil dependency requires it.

However, after including the generated config.mk, test/Makefile unconditionally appends -std=c++14. The resulting compiler options contain:

-std=c++17 ... -std=c++14

Because the last -std option takes precedence, unit tests are compiled as C++14. With Protobuf 25.1 and Abseil 20230802, this causes compilation failures in Abseil headers, including:

absl/strings/cord.h:1020:18:
error: cannot convert ... lambda ... to int

The failure was reproduced for the following targets:

• brpc_load_balancer_unittest.o
• brpc_builtin_service_unittest.o

Keeping all other compiler options unchanged and making C++17 the effective standard allowed both targets to compile successfully.

What is changed and the side effects?

Changed:

Remove the test-specific -std=c++14 option from test/Makefile, allowing the test build to inherit the C++ standard selected by config_brpc.sh through config.mk.

The resulting behavior is:

• Protobuf 22 or newer: tests inherit C++17.
• Older Protobuf versions: tests inherit the configured C++14 baseline.

This prevents test/Makefile from overriding the C++ standard selected according to the dependency version.

Validation environment:

openEuler 24.03 LTS-SP4, x86_64
GCC 12.3.1
Protobuf 25.1
Abseil 20230802.1
GoogleTest/GoogleMock 1.14.0

Validation performed:

• Reproduced the Abseil compilation error with C++14 as the effective standard.
• Confirmed both affected targets compile when C++17 is the effective standard.
• Successfully rebuilt both targets through the modified test/Makefile.
• Successfully linked both corresponding test binaries.
• Successfully built and linked the complete test directory with make -j2.
• brpc_builtin_service_unittest: 21 tests passed.
• brpc_load_balancer_unittest: 15 tests passed with the long-running LoadBalancerTest.fairness benchmark excluded.

The complete brpc_load_balancer_unittest run did not finish within the five-minute local timeout while running the fairness benchmark. No assertion failure was observed before the timeout.

Side effects:

• Performance effects: None. This only changes how the test build obtains its C++ standard.
• Breaking backward compatibility: No. Configurations using older Protobuf versions continue to inherit the C++14 baseline.