Add attributes to symbols and `noexcept` specifiers

[mikomikotaishi]

Is your feature request related to a problem? Please describe.
Discarding retrieved values is often unintended during compilation, however the compiler by default does not report these. This can be a point or even source of bugs. Furthermore, without directly checking documentation one does not always have access to a list of deprecated symbols. If we use attributes (which have been available since C++11), we can report most of these issues during compilation.

It would be preferable if unused values had to be manually suppressed (i.e. using (void)) to prevent these potential sources of accidents.

Furthermore, many getter and setter methods, which simply reassign values or return values themselves, are (mostly) obvious not to throw exceptions. However, they are not marked noexcept in many classes (for example Poco::Crypto::{CipherKey, CipherKeyImpl}; in fact after iterating through each class I have found this is generally true and there is not much use of noexcept in the library). We could make use of compiler optimisations by taking advantage of noexcept in such locations.

Describe the solution you'd like
I would like:

• Mark getter methods and functions that are otherwise intended to retrieve values (rather than perform mutation) to be marked [[nodiscard]], as a diagnostic for unused values. For example, any method that is named "is", "get", etc.
• Mark classes and structs that represent data (i.e. records) [[nodiscard]], to prevent accidentally producing temporary objects that do not get used
• Mark functions that do not return (if applicable) [[noreturn]]
• Mark obsolescent or deprecated functions or classes [[deprecated]] Already done by POCO_DEPRECATED().
• Mark methods (such as getters and setters) which are guaranteed not to throw exceptions, noexcept
• Wherever else possible, make use of attributes like [[likely]], [[unlikely]], [[assume()]], [[no_unique_address]], and [[fallthrough]], to potentially use compiler optimisations, if the situation calls for them.

Describe alternatives you've considered
No such alternatives to this feature exist in the language.

Additional context
For attributes like [[nodiscard]] and [[deprecated]], an optional parameter may be supplied specifying a reason that the symbol should not be ignored, or why the symbol is deprecated. If possible, we should include these.

[mikomikotaishi]

Ah, perhaps this issue should have been marked "enhancement" rather than "feature". I'm not able to change the tags, so please change the tag for me

[mikomikotaishi]

I'm going to be making a PR adding [[nodiscard]] for various methods that I believe it should apply to. Unlike POCO_DEPRECATED() which can be disabled, I am not going to put [[nodiscard]] behind a macro as using deprecated symbols is intended while discarding a value is certainly a programming error.