added new asset permission flags pay_fees_core_only and exchange_restricted

https://github.com/alexpmorris/bitshares-core/commits/pay_fees_core_only

I added code for two new asset permission flags:

```
pay_fees_core_only = 0x200, /** < require asset-related fees to be paid in core asset only (ie. BTS) */
exchange_restricted = 0x400 /**< only the issuer can offer asset for sale on exchange */
```
* `pay_fees_core_only` is especially useful for 0 precision assets, such as those that have been created by @officialfuzzy and others to be used as STEEMIT tokens. Many times, when new bitshares users are given these tokens they do not yet fully understand the system, and often do not have any BTS available to use as fees. As such, they end up using WHALESHARE, HAIRSHARE, BEYONDBIT, etc in lieu of BTS as transfer fees. Since these assets are indivisible, the fee costs multiples of the .24 BTS fee that is generally charged. Having this optional flag set by the asset issuer forces users of these tokens to pay associated fees in BTS, and thus avoids the bitterness caused by dramatically overpaying on their first (or first few) transfers before they realize the mistake they are making.

* Yesterday in the telegram chat Bill Butler wrote the following:
>What I'd really like to do is create tokens and then offer them for sale on the exchange in tranches.
1000 for $.10
1000 for $.50
1000 for $1.00
And disallow trading while the "ICO" is underway. This effectively eliminates competition from scalpers while I'm raising money. Otherwise, I'll have people buying them for $.10 and turning around to sell them for $.40 or $.90 to undercut the next tranches. The cool part about this is that I could actually post the entire sell order book immediately so my ICO was transparent to all. Then, once all tokens have been sold, I've raised my money and I can lift the vesting limitation.

* By adding `exchange_restricted`, I believe it solves what he'd like to do by only allowing the issuer to sell the asset on the market (post on the book) while the flag is active for that asset. Furthermore, he can limit transfer of the asset by also enabling the `transfer_restricted` flag. The comment for `transfer_restricted` implied it may have been intended to support a similar feature *( ... or market orders)*, however it doesn't seem that aspect was ever implemented *(as far as I could tell)*:

```
/// @return true if this asset may only be transferred to/from the issuer or market orders
bool is_transfer_restricted()const { return options.flags & transfer_restricted; }
```

I think both features would be valuable to add because they serve to promote more liquidity by enticing potential ICO / token issuers with more options, and also by helping prevent newer users from overpaying fees and thus having second thoughts over using the platform. If these additions are accepted, it should be relatively trivial to add additional toggles into the GUI to enable/disable these features.

* assertion triggered by `pay_fees_core_only`:
```
fee_asset->get_id() == asset_id_type(): Fees for asset WHALEHOLE must be paid in BTS
{"asset":"WHALEHOLE","core":"BTS"}
th_a evaluator.cpp:77 prepare_fee
```

* assertion created by `exchange_restricted`:
```
_sell_asset->issuer == _seller->get_id(): Only issuer seller can sell WHALEHOLE on market
{"issuer":"seller","asset":"WHALEHOLE"}
th_a market_evaluator.cpp:68 do_evaluate
```

Start with the proposed changes on the pay_fees_core_only branch, then read fee preparation at evaluator.cpp:77 and market validation at market_evaluator.cpp:68. Check how the existing asset permission flags are represented and enforced. Done means both assertions behave as described for the new flags and the core behavior is covered by the project's relevant tests.

Written by the indexing model from the issue text.