The TF provider’s knowledge of cloud account object is older and
different from the actual BE cloud account. This is because BE has
modified the account object with fields like organization_id during
org onboarding. Hence, during intended PUTs, TF overwrites these
fields resulting in unexpected state.

Fix summary:
------------
1. Add and expose the organization_id in provider's account resource schema
   (as a computed field only). This is to let the customers know if their
   onboarded account is part of any org when they fetch the real existing
   infrastructure objects using GET calls.
2. During resource updates (PUT API calls) restrict and reject with error
   when the customer tries to update any non-updatable resource fields.
3. Minor refactoring for cleaner code.

Testing done:
---------------
Validated the scenarios :-
- During tf apply again --> it returns and updates organization_id on the account.
- No unnecessary PUTs
- On triggering an intended PUT :-
  - restricts any non-updatable fields
  - PUT works as expected, doesn't oevrwrite organization_id to ""