Improve get_required_fees API for proposal_create_operation

**User Story**

As an API user I want to accurately calculate required fees for my `proposal_create_operation` when fee asset of proposed operation inside the proposal is different.

Currently the `get_required_fees` API accepts one fee asset type only, when the operation is a `proposal_create_operation`, the API recursively calculates fees for all proposed operations with the specified fee asset, and return a nested structure. That said, asset type of fees of the nested operations will be updated to the specified asset type before calculating. This approach will potentially change the "packed size" of the `proposal_create_operation`, so the returned fee amount could be too small.

Ideally if the API client is able to query for required fees in different asset types for the whole `proposal_create_operation` with one API call, but it's hard to find a proper way to pass in multiple asset types for different purposes. We want the API to be simple to understand and easy to use.

An simplified approach is, don't recursively calculate fees for `proposal_create_operation`, nor update fee asset types for nested operations, but only return the fee for the `proposal_create_operation` itself. If a client developer wants to query for fees for the nested operations as well, she can do another API call with the operations as parameter directly. If we go with this approach, for backward compatibility, we can't simply change the behavior of current API, instead, we can add a new optional parameter to the API to indicate whether the client wants to recursively calculate fees.

**Impacts**
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.
- [x] API (the application programming interface)
- [ ] Build (the build process or something prior to compiled code)
- [ ] CLI (the command line wallet)
- [ ] Deployment (the deployment process after building such as Docker, Travis, etc.)
- [ ] DEX (the Decentralized EXchange, market engine, etc.)
- [ ] P2P (the peer-to-peer network for transaction/block propagation)
- [ ] Performance (system or user efficiency, etc.)
- [ ] Protocol (the blockchain logic, consensus, validation, etc.)
- [ ] Security (the security of system or user data, etc.)
- [x] UX (the User Experience)
- [ ] Other (please add below)

**Additional Context (optional)**
Add any other context about your request here.

## CORE TEAM TASK LIST
- [ ] Evaluate / Prioritize Feature Request
- [ ] Refine User Stories / Requirements
- [ ] Define Test Cases
- [ ] Design / Develop Solution
- [ ] Perform QA/Testing
- [ ] Update Documentation

Start at the get_required_fees API and its handling of proposal_create_operation. Define how an optional parameter controls recursive fee calculation while preserving current behavior for existing clients. Done means the API can return the proposal's own fee without rewriting nested fee assets, while still supporting recursive calculation when requested.

Written by the indexing model from the issue text.