Add [[nodiscard]] annotations to generated C++ code

[AaronWebster]

Summary

Consider adding [[nodiscard]] annotations to generated C++ code for methods like Ok(), Read(), TryToWrite(), etc. to help catch bugs where return values are accidentally ignored.

Background

This was originally part of PR #235 (optimization for conditional fields), but was requested to be split out for separate discussion since [[nodiscard]] is a C++17 feature and there may need to be a broader discussion about C++14 vs C++17 support.

Considerations

• [[nodiscard]] was introduced in C++17
• Current Emboss may support C++14 users
• Options to consider:
  1. Require C++17 minimum and add [[nodiscard]] unconditionally
  2. Use a macro that expands to [[nodiscard]] on C++17+ and nothing on C++14
  3. Keep C++14 compatibility and don't add [[nodiscard]]

Affected methods

Key methods that would benefit from [[nodiscard]]:

• Ok() - return value indicates validity
• Read() / UncheckedRead() - return values are the point of the call
• TryToWrite() / TryToCopyFrom() - return value indicates success
• IsComplete() - return value indicates completeness
• CouldWriteValue() - return value indicates writability

cc @EricRahm (requested this be discussed separately)

[EricRahm]

Background

So we still claim to support C++11:

emboss/doc/guide.md

Lines 43 to 46 in e24ea8c

	The code generated by Emboss requires a C++11-compliant compiler, and a
	reasonably up-to-date standard library. Emboss has been tested with GCC and
	Clang, libc++ and libstd++. In theory, it should work with MSVC, ICC, etc., but
	it has not been tested, so there are likely to be bugs.

but we also have an "at least 10 years" rule that spells out support, we don't include C++11 there:

emboss/doc/cpp-dark-corners.md

Lines 209 to 228 in e24ea8c

	## Emboss Compatibility
	Emboss has a very long backwards-compatibility guarantee for C++: a standard
	must have been released for at least 10 years before Emboss can rely on it.
	| Standard | Release Date | Emboss Support Until |
	| -------- | ------------ | -------------------- |
	| C++14 | 2014-12 | 2028-01-01 |
	| C++17 | 2017-12 | 2031-01-01 |
	| C++20 | 2020-12 | 2034-11-01 |
	| C++23 | 2024-10 | 2037-01-01? |
	This kind of long guarantee is common in the embedded development space, where
	compilers are often provided by vendors, and are often old versions (for
	example, at least one team using Emboss for active development was still using
	a vendor-provided C++11 compiler in late 2024).
	Unfortunately, this means that Emboss developers must be aware of and avoid
	dark corners that have been fixed in the latest versions of C++, or bugs that
	have been fixed in newer versions of C++ compilers.

And a cursory test of compiling against C++11 found some issues like:

In file included from compiler/back_end/cpp/testcode/cpp11_compliance_test.cc:1:
In file included from bazel-out/k8-fastbuild/bin/testdata/float.emb.h:15:
./runtime/cpp/emboss_prelude.h:773:5: error: use of this statement in a constexpr function is a C++14 extension [-Werror,-Wc++14-extensions]
  773 |     static_cast<void>(value);
      |     ^

So all that said, I think we could probably remove language referring to C++11, but we'll still support C++14 for a while.

Next steps

I'm still supportive of adding a [[nodiscard]]-like thing, but we'll probably need to polyfill it. Perhaps something like:

#if !defined(EMBOSS_NODISCARD)
// In C++17 and later, use the standard [[nodiscard]] attribute.
// Some compilers (like MSVC and recent Clang) support [[nodiscard]] in C++14
// mode, but it might trigger "extension" warnings, so we stick to the version check.
#if defined(__cplusplus) && __cplusplus >= 201703L
#define EMBOSS_NODISCARD [[nodiscard]]
#elif defined(__clang__) || defined(__GNUC__)
#define EMBOSS_NODISCARD __attribute__((warn_unused_result))
#elif defined(_MSC_VER) && _MSC_VER >= 1700
#define EMBOSS_NODISCARD _Check_return_
#else
#define EMBOSS_NODISCARD
#endif
#endif  // !defined(EMBOSS_NODISCARD)