Document depreciation of MULTIPLY inside [DEMANDS] section of INP

[lbutler]

In epanet 2.2 it was possible to set the demand multiplier inside the [DEMANDS] section of the input file.

[DEMANDS]
   MULTIPLY  factor
   node  base_demand  (pattern)

This was not a documented feature, and it was only mentioned inside the source code in input3.c here:

https://github.com/OpenWaterAnalytics/EPANET/blob/7b640122cdd3de25abcca2cadcafc1cd206d2106/src/input3.c#L771-L781

https://github.com/OpenWaterAnalytics/EPANET/blob/7b640122cdd3de25abcca2cadcafc1cd206d2106/src/input3.c#L801-L807

The only reason I know this exists is because we unexpectedly ran into it throwing error 213 in junction with ids of mult* and demand 0.

Interestingly this multiplier work with the GUI, but only with the keyword MULTIPLY, not MULT in the toolkit.

I was originally going to suggest maybe we depreciate it because it was causing issues with junctions but it’s already been done in PR #758.

My suggestion now is that we include a note in ReleaseNotes2_3.md that this undocumented feature was removed and that the multiplier now must be set inside [OPTIONS] - we can also clean up some remaining constants in text.h

[lbutler]

I had a look through and checked to see if there was anything else missing in ReleaseNotes2_3.md and there were a couple of items.

I'm going to open a PR soon with the following updates:

• Setting the demand multiplier within the [DEMANDS] section of INP has been depreciated, please use DEMAND MULTIPLIER inside [OPTIONS] instead.
• EN_PRESS_UNITS can now be used with EN_getoption and EN_setoption to get or set the pressure unit used in EPANET. (Reference PR https://github.com/OpenWaterAnalytics/EPANET/pull/719)
• Continuous barrier functions were added to constrain emitter flows to allowable values (Reference PR https://github.com/OpenWaterAnalytics/EPANET/pull/721)
• The EN_openx function has been added to enable the opening of input files with formatting errors through the API. This allows users to continue using toolkit functions even when such errors are present. (Reference PR https://github.com/OpenWaterAnalytics/EPANET/pull/758)