[JENKINS-71956] Octal notation fixes

[Vlatombe]

Context
Kubernetes-client uses jackson-databind to parse yaml into objects, using snakeyaml.
Kubernetes-client has migrated their serialization methods to use SnakeYAML engine (fabric8io/kubernetes-client#4836)

The problem is that snakeyaml uses yaml 1.1 while snakeyaml-engine only supports yaml 1.2.

This causes inconsistencies when dealing with integer with the octal notation, as there are breaking changes between these two versions. Additionally, FasterXML/jackson-dataformats-text#3 documents that octal notation is not properly supported through jackson.

Plugin perspective

This follows up #1342, already providing some octal notation conversion.

User yaml is still expected to use yaml 1.1, using the 0xxx notation for octal integers. For a series of known paths in the pod spec, an automatic conversion will happen.

This behaviour can be disabled using -Dorg.csanchez.jenkins.plugins.kubernetes.PodTemplateUtils.DISABLE_OCTAL_MODES=true in case users have converted their yaml manifests to use decimal notation instead. A best effort is attempted to keep modes that have been provided using decimal notation, but this can't be foolproof.

Going forward, jackson 3.0 will use SnakeYAML engine so hopefully we will eventually get a more consistent behaviour, but I expect possible new breaking changes when it happens.

This adds a few paths I missed when I initially addressed this kubernetes-client upgrade in #1342, as well as providing unit tests.

Testing done

### Submitter checklist
- [ ] Make sure you are opening from a **topic/feature/bugfix branch** (right side) and not your main branch!
- [ ] Ensure that the pull request title represents the desired changelog entry
- [ ] Please describe what you did
- [ ] Link to relevant issues in GitHub or Jira
- [ ] Link to relevant pull requests, esp. upstream and downstream changes
- [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jglick]

I wonder if we could make this more reliable by checking the octal representation (reference). Actual modes will normally have the group bits match either the user bits or the other bits (it would be weird to have three different octets). And normally u ≥ g ≥ o and w ≥ r ≥ x right? For example 777 satisfies all constraints whereas 511 in octal would be -r-x--x--x which violates r ≥ x for g/o and is thus technically legal for exotic scenarios but unlikely to be what the user meant.