Fix learning rate schedule in Megatron models when `max_steps` is not set
# What does this PR do ?

This fixes the learning rate schedule in Megatron models when relying on `max_epochs` instead of `max_steps`.

The issue is that [compute_max_steps](https://github.com/NVIDIA/NeMo/blob/bdea326811ef81d3aff3530b26b67f7a7ce5119c/nemo/core/optim/lr_scheduler.py#L934) is incorrect for Megatron models since `accumulate_grad_batches` is equal to 1 from PTL's perspective, even if we are actually using multiple micro-batches.

**Collection**: nlp

# Changelog 
- Fix learning rate schedule in Megatron models when `max_steps` is not set

# Before your PR is "Ready for review"
**Pre checks**:
- [X] Make sure you read and followed [Contributor guidelines](https://github.com/NVIDIA/NeMo/blob/main/CONTRIBUTING.md)
- [ ] Did you write any new necessary tests?
- [ ] Did you add or update any necessary documentation?
- [ ] Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc)
  - [ ] Reviewer: Does the PR have correct import guards for all optional libraries?
  
**PR Type**:
- [ ] New Feature
- [X] Bugfix
- [ ] Documentation

## Who can review?

Anyone in the community is free to review the PR once the checks have passed. 
[Contributor guidelines](https://github.com/NVIDIA/NeMo/blob/main/CONTRIBUTING.md) contains specific people who can review PRs to various areas.

# Additional Information

I considered two potential implementations:

1. (this one) setting `max_steps` directly in `MegatronBaseModel`
2. Setting `t_accumulate_grad_batches` correctly in the scheduler config so that the formula is correct

I didn't go with (2) because it seemed trickier to ensure that all parameters are correct so that the formula works, including with drop_last which [still raises an old warning](https://github.com/NVIDIA/NeMo/blob/a420f9083ea9993152a5221b8875c34470561f13/nemo/core/optim/lr_scheduler.py#L943). It's easier to just compute `max_steps` within `MegatronBaseModel`.

cc @aklife97 