Fix junos confirm-commit issue (improved version)

[attila123]

Based on @ganeshrn fix (#239), but also clear the namespace for commit-configuration element (https://www.juniper.net/documentation/en_US/junos/topics/reference/tag-summary/junos-xml-protocol-commit-configuration.html) and update the corresponding unit tests.
I also tested it with a real Juniper SRX 300.

[coveralls]

Coverage increased (+0.03%) to 69.044% when pulling 476639e on attila123:junos_confirm_commit_fix into 76d274b on ncclient:master.

[ganeshrn]

imo the api should accept timeout value in minutes only as the junos rpc takes the value of timeout in minutes. With the current logic if the user input 121 sec it will end up waiting for rollback for 3 mins (ie. 180 sec) which seems incorrect to me.

[attila123]

"imo the api should accept timeout value in minutes only as the junos rpc takes the value of timeout in minutes."
@ganeshrn the problem with this is that the ncclient library (and netconf) uses timeout in seconds, so if you don't provide seconds there, you break the API of ncclient library. The standard rpc for confirmed commit does not seem to work for Junos, so we are forced to wrap their proprietary and incompatible rpc to the standard API of ncclient, and convert the seconds to minutes in the best possible way.
IMHO, for practical purposes, one minute difference does not matter much for confirmed commit. Realistically, the timeout should be at least 10 minutes (default value in the protocol) to leave enough time for testing after configuration. But I am not a network engineer, do not have practical experience here. And it is better to leave one extra minute for the testing rather than timeout a bit earlier. To put it another way (this is the only thing I can imagine to support your opinion): in case of a totally bad config one might generate one extra minute of outage.
In any case thank you very much helping to fix this! :)